Hi Dan, Conceptually this makes sense to me. Obviously you can do that check inside the BVP, but moving it to a more declarative model would I'm sure be useful. One thing to think about is resource type inhiertance. I assume we would want BVPs to be inherited.
Justin On Fri, Dec 6, 2013 at 12:11 PM, Daniel Klco <[email protected]> wrote: > 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 > <[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 >>
