You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2013/12/06 17:40:49 UTC
FYI, request setup script prototype
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
Re: FYI, request setup script prototype
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Fri, Dec 6, 2013 at 6:11 PM, Daniel Klco <da...@gmail.com> 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....
Sounds interesting, as long as you can script the BVP code which is
certainly possible.
The whole idea of being to resolve arbitrary "things" based on
resource types has been in the back of my mind for quite some time,
looks like it would be useful in several places.
You could probably use, at least for experimenting, a similar trick
than in my prototype. i.e. resolve a script with a fake extension to
take advantage of Script's resolution.
-Bertrand
Re: FYI, request setup script prototype
Posted by Justin Edelson <ju...@justinedelson.com>.
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 <da...@gmail.com> 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 <ju...@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
>> <bd...@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
>>
Re: FYI, request setup script prototype
Posted by Daniel Klco <da...@gmail.com>.
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 <ju...@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
> <bd...@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
>
Re: FYI, request setup script prototype
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Sun, Dec 8, 2013 at 6:53 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...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...
I agree that folding this into BVPs sounds interesting and would avoid
inventing more new things than needed.
Especially if we can generalize the mechanism that finds the best
service (BVP in this case) to handle a given Resource, based on our
existing resource script resolution rules.
To me the main use cases are:
1) Create lightweight domain objects which can be scripted as well as
written in Java, and take care of assembling/formatting/defaulting
values for presentation, as well as providing smart iterators, for
search results pagination for example.
2) Act as mini-controllers that can redirect, fail or forward the
current request to take that code out of rendering templates. This is
out of scope of BVPs currently, but does also not generally belong
into rendering templates.
For now, I'll just keep my whiteboard prototype [1] around and see
where this goes.
Thanks everybody for the feedback!
-Bertrand
[1] https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/request-context
Re: FYI, request setup script prototype
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <ju...@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
> <ak...@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 <ju...@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
> >> <bd...@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
cziegeler@apache.org
Re: FYI, request setup script prototype
Posted by Justin Edelson <ju...@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
<ak...@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 <ju...@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
>> <bd...@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
>
Re: FYI, request setup script prototype
Posted by Alexander Klimetschek <ak...@adobe.com>.
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 <ju...@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
> <bd...@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
Re: FYI, request setup script prototype
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Fri, Dec 6, 2013 at 5:48 PM, Justin Edelson <ju...@justinedelson.com> wrote:
> ...This looks a bit too magical to me :) All you're avoiding is a single
> include line, right? Or am I missing something?...
In the current example you're correct, as I'm using an ESP script for
rendering this could just include the setup.ecma code.
It's different when using scriptless rendering languages - like
Velocity maybe, where this would make more sense.
-Bertrand
Re: FYI, request setup script prototype
Posted by Justin Edelson <ju...@justinedelson.com>.
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
<bd...@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