More context in CustomSelector


#1

It would be great if the service being run on a CustomSelector could have some more details about the context of where it is being run. F.ex. that I in the service could get details about what content type the CustomSelector is being used from, and also possible path and ID to the object that is being edited. This can allow us to make smarter services and let the customselector predict better what results to display.

I guess this can also solve this issue here CustomSelector dependant on other input to allow the service to be dependant on other values from the object.


#2

Hi Johenrik :slight_smile:

Sending content ID (and possibly content type) as parameters to the service sounds like a useful feature. It will not help solving input dependencies within a single document though. :thinking:

Could you also provide some specific use-cases where you would apply this feature?


#3

In the specific use case requested by the customer here we only need the content type. They have a lot of codes in various formats that is used to tag content. These are in various different code systems and we have a service that search through the different code systems. If I search for A70 I am shown options looking like:
A70 (System A)
A70.3 (System B)
A700 (System X)

We have this same service on very many content types on the site. Ideally we would like this service to check content type and do some changes to the results of the service. Some content types should not allow tagging with System B, and others should not be allowed to tag with System X.

We would like to avoid having to create one service per content types as they are so similar and look through the same type of content. Knowing the content type inside the service we would be able to adjust our query based on this and avoid lots of duplicate code.


#4

We have added this to our backlog. We will pass enough context to get what you need.


#5