Custom displayLibrary.cfm views in array properties

Found an problem when creating content specific displayLibrary.cfm in 6-1-1.

For example, the main content type CT01 with an array property aCT02 joining type CT02. To create a library picker for aCT02 you need to put the displayLibrary.cfm in /webskin/CT01 and not /webskin/CT02.

This seems wrong as the library picker is for picking type CT02.

The problem is that the parent content object admin is calling /core/webskin/fourq/displayLibraryTabs.cfm and this is running the following code to get the displayLibrary.cfm view:

<skin:view stobject="#stobj#" webskin="displayLibrary" />

This is picking up the library picker from the parent content item (stobj).

h/t 2011-11-19 Google Groups

Hi Chris,

Looks like I’m 3 years behind you.

It indeed seems to work in an odd way. Did you ever resolve it?

In the mean time I’ve used:

<skin:view stobject="#stobj#" webskin="displayLibrary" typename="#stMetadata.ftJoin#"  />

Seems to work so far.

I suspect the logic behind this is that the view is on the object being edited – that is, you might need a custom way of picking that library content type, rather than defaulting to a view on the picked item.

Mind you, a view on the picked item would give you a handy global change to picking that content type :smile:

It would help to know a little bit about your content types, the property on which you are doing the join, and maybe some screenshots which show what result you are getting and what you might expect to be different.

The way the library picker works, it is a view on the content type which the property belongs to, rather than the types you are joining to.

This really all come about because I’ve been working with the google maps plugin. I’ve extended the mapslocation type to include a country code. When creating a map, adding locations becomes problematic if you want to do a quick search on fields other than label. ie search on country code.

The fix above does work to initially displaying the correct displayLibrary but then it defaults to the parent typename once you search or hit the pagination.

It does seem sensible to have a global displayLibrary kind of webskin for each content type.

BTW if you wanted to improve the Maps Plugin directly to incorporate better features (as opposed to extending it) please let us know. It’s been a while since anyone has worked on that plugin and it probably needs a facelift.

I’ve had a bit of a look at how the library picker currently works, and in general displayLibraryTabs and displayLibrary needs to be a view on the content type that the array property belongs to (mostly due to the JS events that pass data back to the content object being edited).

For your use case it looks like what you want to customise is the search form (displayLibrary.cfm lines 123 to 132) and the query filtering (displayLibrary.cfm lines 35 to 85). Does that sound right?

If so it might be beneficial to split those in to component methods / webskins so that they can be overridden per content type.

This has come up in our rollout of FC7 for new sites. A lot of our users would like to be able to use a particular node of categories–> image assignments when using the picker to add an image to an object.

To write a custom picker for an object, would you basically need a displayLibraryTabs and displayLibrary file in the webskin for the parent object? Would there be a way to have different pickers for different child objects? For instance, Image objects look at a node of categories reserved for images while news objects that might be assigned to a particular rule are looking at a different category node?