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.
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.
Could you also provide some specific use-cases where you would apply this feature?
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.
