CustomSelector, store more than just an "id-string"

It would make the CustomSelectors alot more powerfull if you were able to save a data object together with the ID.

Now it aint possible to query based on a selected item (unless you know the ID ofc) and if you’re doing a freetext search you won’t get much help from it…

I do see the issue with having potential data being outdated, but that can ofc. be solved in multiple ways.

Lets look at a very fictive example:

You create a MyCustomVideoSelectorService to select a video from your Video Archive, that works and adds it to one of your components.
Everything works like a charm and you’re feeling like a rockstar! :fist:

A visitor comes to your site and burst out:
wow so many amazing videos!

I want mooore videos from this genre

Tries to do a site search for “sci-fi” :zero: hits

Creates a angry post on Facebook

You know you have all this meta data is already available in the system…

The designer :nerd: also had a plan for a “videos like this” part looking at only the published videos in this section of the site and with the :muscle: of Enonic XP content query language you thought it would be a quick job on friday… but now you must query the external archive with all IDs in the section AND the suitable metadata and you can’t go for a :beer: early…


Interesting proposal indeed, and technically we could support storing a propertyset rather than just a string.

However, for your specific usecase importing content sounds like a better solution than using a contentselector?

Lets say we have 500GB of images stored in our DAM (Digital Asset Management) system. Importing all these images would be a waste of resources if we only use <1%.

… the example with video is also different since you most likely would like to have the video archive system support handle different formats and feeds, and not have to select all those in XP.

Regarding the mentioned DAM @tommytusj mentioned would most likely not work well with a customselector either way, since you cant create a CustomSelector that support images (setting focus/crop) in XP.
So guess that’s another feature request to be able to declare a CustomSelector to be of type “image” and implement some interface and in that way be able to store focus/crop information in XP but refering to an original src on a external system.

Why not just import what is needed? Create a “CMS” folder in the DAM and add all relevant resources to this directory? By importing “web-enabled” versions of the assets you would be able to use XP’s built-in image handling too :slight_smile:

Again - solved nicely with imports as mentioned above.

To create and keep a import in sync may not always be so easy @tsi … so I dont think your solution to “import everything into XP and just work in XP for all your needs” is suitable in organisations where XP is just a small part of the whole system.

What DAM are you using, maybe a “connector app” for your DAM would be the best solution?

Being able to store a JSON object instead of just a string would also let you make a CustomSelector that is more than just an “id selector”.

You could, for instance, use the Google Search API to allow the user to select an external URL. The selector would search Google, and when one of the options are selected from the drop down, the selector stores { url: "", title: "VG Nett", subtitle: "Dagens nyheter fra VG Nett" } which is enough information to both show the “selected options”-list and to use that selected content when rendering without doing another search (which is not even possible with todays solution, since Google doesn’t really have ID’s). The custom selector would not enforce any particular keys to be preset in the object stored. It would be the developers responsibility to store enough data to be able to list the selected options later on.

A different use case might be a Custom Selector that lets you search both Spotify and YouTube Music for sound clips. If I was able to save { type: "youtube", id: "kslkd783l" } or { type: "spotify", id: "kslkd783l" } I could easily search the correct API to retrieve information about the ID when the user needs to list the selected contents. With the custom selector solution like it is right now, I would have to hack something together by splitting the string using a delimiter or something.

I think the idea behind this suggestion is that this would empower the developer to come up with use cases beyond what we can even imagine right now. More generic interface = better :slight_smile:


We definetly get the idea - but as this rises comlexity the best solution for such cases might be custom input types rather than trying to make customSelector bend over backwards?

Yes please!, both options to make custom input types AND make the Custom Selector bend over :wink:

Hi Edward and Espen,

Support for storing more data for custom selectors is in our backlog now and scheduled for Q3.