Re: FYI, request setup script prototype
Hi, On Fri, Dec 6, 2013 at 6:11 PM, Daniel Klco daniel.k...@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
On Sun, Dec 8, 2013 at 6:53 AM, Carsten Ziegeler cziege...@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
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
Re: FYI, request setup script prototype
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
Re: FYI, request setup script prototype
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.comwrote: 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
Re: FYI, request setup script prototype
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
Re: FYI, request setup script prototype
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 daniel.k...@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 jus...@justinedelson.comwrote: 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
Re: FYI, request setup script prototype
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
