>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. 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'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. this is getting a long thread, i'll write a summary to lead to a decision. stefan
