hello justin. >> 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.
in our current approach the post processing step should not be separate, and the user of the models should not be aware of it. but we are still in the first few months of developing our new architecture style based on sling models, perhaps we think otherwise a few months ahead when the first applications with it are finished. it is too early for me to make a final judgement. coming back to my summary post [1] I have the feeling we should go with A) currently, and see if others have the same needs for such a threadlocal in the future - or not. unit then i can continue experiment with it outside the main sling build. stefan [1] http://apache-sling.73963.n3.nabble.com/RE-RTC-ThreadLocal-for-getting-current-request-in-sling-summary-tt4042631.html > >> 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 >>
