The script resolution is already a complicated thing and this adds another layer to it - and I guess if this is used you would need scoping, so if you include another resource this might require a different setup and once the include finished, the old context needs to be restored etc. We already have the BVP, now with the ability to bind BVPs to a context (or whatever the term is). I think we should rather focus on one feature and getting it right than spreading similar functionality across different features which all look similar but behave differently
Carsten 2013/12/7 Justin Edelson <jus...@justinedelson.com> > Hi Alex, > One minor point - IIUC, the Use directive defines have a specific > scope *within* a Sightly template. In this regard, they are slightly > different than what Bertrand is doing or what a BVP does which operate > around the template as a whole. > > To me, a Use class is more like an AngularJS controller, the 'with' > keyword in JavaScript, the 'use' keyword in Groovy, or Droplet > oparams. > > Regards, > Justin > > On Fri, Dec 6, 2013 at 12:25 PM, Alexander Klimetschek > <aklim...@adobe.com> wrote: > > Right. Sightly has the concept of a "Use" class (*). It is triggered > from the template using a certain command/include. This use class can be > either > > a) next to the script in the resource type folder (using the Java script > engine if it's in Java, I think it could also be written in Javascript, in > which case it uses the Javascript scrip engine) > > b) or it can be in a osgi bundle with the right package name (based on > the rt) > > c) or it can be in a osgi bundle at any place (when addressed by fully > qualified class name) > > > > It has to extend a base class that will get the basic sling request > information. But this can also be an extended base class that includes > more: say in a CMS on top of Sling, there would be CMS specific base class > that provides more context than the plain Sling stuff. > > > > The important part in this excercise is that it can be resource type > based a) (specific logic just for the templates of that rt), but also > easily shared among multiple resource types (c). Also, with super resource > types things you want to be sure the correct use class is being used. > > > > So while I think it could be nice to have this happen more generically > as part of the resource type execution, you need some place to specify that > use class or request context helper. If we take it out of the template, > where should it go? You could put it into the rt folder as e.g. jcr > property - but what if different templates in the same rt want to use a > different one? (Maybe that's something to avoid and we force it to be > shared among all the templates within one rt). > > > > (*) like a bean, but wanted to avoid confusion of that name, so because > the templates "uses" it, it's called that way) > > > > Cheers, > > Alex > > > > On 06.12.2013, at 08:48, Justin Edelson <jus...@justinedelson.com> > wrote: > > > >> Hi Bertrand, > >> This looks a bit too magical to me :) All you're avoiding is a single > >> include line, right? Or am I missing something? > >> > >> You could also do the same thing (more or less) with a > BindingsValuesProvider. > >> > >> Justin > >> > >> > >> > >> On Fri, Dec 6, 2013 at 11:40 AM, Bertrand Delacretaz > >> <bdelacre...@apache.org> wrote: > >>> Hi, > >>> > >>> From the funky prototypes department: I was talking to a colleague > >>> this week about how to minimize the amount of code in presentation > >>> templates, and we came up with the idea of having a setup script run > >>> at the beginning of the request processing, to prepare values, > >>> functions, iterators etc. for rendering scripts. > >>> > >>> I have created a prototype at > >>> > https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/request-context > >>> - to play with it, install it, request > >>> http://localhost:8080/apps/requestcontext.html and see the commented > >>> scripts under /apps/requestcontext [2] > >>> > >>> Here's how this works: > >>> > >>> A Filter finds and executes the script that would process the same > >>> request as the current one if it had the "setup" extension, before the > >>> actual request processing takes place. > >>> > >>> In our example that's /apps/requestcontext/setup.ecma which contains > things like > >>> > >>> rc.u.title = "Here's the title for " + rc.path + ", computed at " + > >>> new Date(); > >>> > >>> The rc object is our "request context", that provides easy access to > >>> standard (rc.<name>) and freely defined user values (rc.u.<name>). > >>> > >>> You can then use the rc object in the rendering script, which in this > >>> case would contain just > >>> > >>> <h1><%= rc.u.title %></h1> > >>> > >>> but the title building logic is neatly separated in its own script, > >>> reusable, doesn't pollute rendering etc. > >>> > >>> This might be especially useful in the context of templating languages > >>> like Sightly [1] that want to avoid code in rendering templates. > >>> > >>> The setup script can also play the role of a mini-controller, as it > >>> can redirect, fail or forward the current request. > >>> > >>> My prototype doesn't require any changes to the Sling code, so we can > >>> very keep that as an experimental extension for now, if we want to > >>> move it out of the whiteboard. > >>> > >>> Feedback is welcome as usual. > >>> > >>> -Bertrand > >>> > >>> [1] > http://www.pro-vision.de/content/medialib/pro-vision/production/adaptto/2013/adaptto2013-sightly-gabriel-walt-honwai-wong-senol-tas-pdf/_jcr_content/renditions/rendition.file/adaptto2013-sightly-gabriel-walt-honwai-wong-senol-tas.pdf > >>> > >>> [2] > https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/request-context/src/main/resources/SLING-CONTENT/apps/requestcontext > > > -- Carsten Ziegeler cziege...@apache.org
