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 <[email protected]> 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 <[email protected]> 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 >> <[email protected]> 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 >
