Actually, I've been batting this around in my head for awhile. Make it possible to create BindingsValuesProviders which are constrained by resource type. And a simple service for getting the various default Sling properties from the existing bindings.
Does that make sense? Then you could just bind one of these providers to any number of resource types and retrieve the bound objects in your scripts as per usual. -Dan On Fri, Dec 6, 2013 at 11:48 AM, 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 >
