Hi Dominik, It is true that the ClassUseProvider only deals with resource and request objects, but That's far from the only way to use adaptTo from Sightly scripts.
Justin On Fri, Oct 24, 2014 at 10:40 AM, Dominik Süß <dominik.su...@gmail.com> wrote: > Hi Justin, > > it is not true that no change in sightly would be required sightly use just > tries to adapt resource or request, not any other objects (see > ClassUseProvider L65 ff as to be found in the contribution zip). > > I'm currently searching for the option to solve the case with the least > modifications and least impact but this is the constraint that I couldn't > eliminate. > > Cheers > Dominik > > On Fri, Oct 24, 2014 at 4:32 PM, Justin Edelson <jus...@justinedelson.com> > wrote: > >> Hi Dominik, >> >> Anyone is free to define their own objects which implement Adaptable >> and their own model classes which can be adapted from those adaptable >> classes. This doesn't require any additions to any part of Sling nor >> any changes to Sightly. >> >> Regards, >> Justin >> >> On Fri, Oct 24, 2014 at 10:20 AM, Dominik Süß <dominik.su...@gmail.com> >> wrote: >> > Hey everybody, >> > >> > thinking about this again I also realized that changing the Adaptable >> > Interface or having another one creates more issues then solving. In >> fact >> > it would be way easier to have some generic Wrapperclass that can hold >> the >> > request and another object and implementing Adaptable. >> > >> > This would require some change for the Use semanticts of Sightly to wrap >> > request and resource (currentResource by default but could be overriden >> by >> > parameter) and the Models implementation would use this adaptable instead >> > of request _or_ resource. >> > >> > WDYT? >> > >> > Dominik >> > >> > On Fri, Oct 24, 2014 at 3:34 PM, Justin Edelson < >> jus...@justinedelson.com> >> > wrote: >> > >> >> 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 >> >> > >> >> >>
