Hi Stefan, On Fri, Oct 24, 2014 at 7:53 AM, Stefan Seifert <sseif...@pro-vision.de> wrote: > >>Personally, I don't quite see the use case -- if your AdapterFactory >>(whether it is generated by Sling Models or hand-coded) needs >>request-based context, the adaptable is the request. > > to shed some more light on my usecase an example: > > - a sightly template calls a "controller" model, which adapts from the > current request > - this model wants to output an object structed based on a complex data > structure (e.g. a list of nodes with subnodes) > - this data structure cannot be used directly for output, but some properties > need some special processing > - so we build a set of models for this data structures adapting to a resource > for each node, injecting each other for @ChildResource for the hierarchy > - each of this resource models does post processing on some attributes, e.g. > - resolving a media asset reference to a set of externalized image URLs for > responsive imaging > - externalizing an URL respecting sling short URL mapping > - injecting dummy images or links for invalid references - but only if the > edit mode of the CMS is active. > - this post processing is done with further models that implement the > business logic to solve this centrally > > it is an implementation details of the post processing business models that > they need a request for some part of their job (e.g. distinguish between edit > and preview mode). the caller of the initial adaption is not necessary aware > of this and should not care of it in my point of view.
This is all just an implementation choice. Nothing is forcing you do to the post processing in an object which doesn't have the request. You can just as easily (probably better) do that post processing in an object which has direct access to the request. Or, as Alex suggested, provide the request to those objects once they are adapted. And of course the caller has to be aware that the request is necessary. It is part of the context of that the execution of that post processing. > if you call and OSGi service you do not have to know what services this has > bound internally, OSGi takes care that all are resolved or the service is not > available. I don't think this is the right analogy. You aren't talking about service dependencies, you are talking about the API. If I have a method called getFoo(Object context) and the context object is required for proper execution. If I pass null as the context object, then I shouldn't expect to get a valid response. > > i'm not a fan of the proposals to extend the adaptTo() semantic for this > usecase. not only because its difficult to do it without breaking existing > code (or leads to an interface like Adaptable2), the caller should not have > to now the implementation details for such cross-cutting concern models that > are required deeper in the model structure. for the same reason extending the > sling models factory interface or having additional "setRequest()" methods on > the models are no fitting solutions - the model that is adapted initially is > not the problem, but those further down the hierarchy. > > having an interface like "RequestScope" is basicall going into the right > direction - but who should detect this interface and inject the request? the > sling models implementation? than we have the same problem not able to geht > the request objects if it's not the adaptable. and sling models does not need > such interfaces, its solely based on @Inject annotations. As I said, this has nothing to do with Sling Models. It is a general problem with adapters. Justin > > this is getting a long thread, i'll write a summary to lead to a decision. > > stefan >
