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 2007/10/12 12:35:37 UTC
microsling script resolution rewritten (was: Microsling, first shot...)
On 10/11/07, Felix Meschberger <fm...@gmail.com> wrote:
> ...I am also not sure, whether script resolution according to the resource
> path is actually a good idea...
You're right, that was a bad idea...I have added a
String getResourceType();
method to the Resource interface, which is meant to point to a
repository location where scripts and other definitions can be found.
And rewritten the SlingScriptResolver to use this.
Script names are also based on the request extension now, so for
example if a scripting SlingServlet is looking for a script with a
"vlt" extension:
When rendering a Resource with resourceType=/some/stuff
For a GET request with with URL extension=html
The SlingScriptResolver looks for a script named
/sling/scripts/some/stuff/get.html.vlt
The updated microsling-homepage.html attached to
https://issues.apache.org/jira/browse/SLING-47 contains links to
source code for a quick code walkthrough.
Do you guys think we need to add more stuff to microsling to reflect
the core ideas of the Sling request processing? ResponseFilters maybe?
-Bertrand.
Re: microsling script resolution rewritten (was: Microsling, first
shot...)
Posted by Felix Meschberger <fm...@gmail.com>.
Am Montag, den 15.10.2007, 14:26 +0200 schrieb Bertrand Delacretaz:
> On 10/14/07, Felix Meschberger <fm...@gmail.com> wrote:
>
> > ...As such microsling would have a MicroSlingServlet which has pretty much
> > everything wired and no OSGi, that is no real lifecycle management and
> > extensibility...
>
> Just a small thing to add here: microsling is extensible indeed, at
> least in a static way, by inheriting from MicroSlingServlet and
> redefining its methods as needed, to use other RequestFilters or
> SlingServlets, or prioritize them differently.
Sure.
> Note also, that if people create microsling extensions as separate
> Maven modules, they should be easy to use in Sling OSGi as well, by
> setting up the Maven POMs for OSGi bundle generation (which is a piece
> of cake with the maven-bundle-plugin and maven-scr-plugin from the
> Felix project).
This is why I want to align Sling and microsling. So that people could
start playing around with microsling and migrate to Sling without major
hassles.
Regards
Felix
Re: microsling script resolution rewritten (was: Microsling, first shot...)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/14/07, Felix Meschberger <fm...@gmail.com> wrote:
> ...As such microsling would have a MicroSlingServlet which has pretty much
> everything wired and no OSGi, that is no real lifecycle management and
> extensibility...
Just a small thing to add here: microsling is extensible indeed, at
least in a static way, by inheriting from MicroSlingServlet and
redefining its methods as needed, to use other RequestFilters or
SlingServlets, or prioritize them differently.
Of course this is no comparison with Sling OSGi - which I love, for
settings which require that kind of extensibility.
Note also, that if people create microsling extensions as separate
Maven modules, they should be easy to use in Sling OSGi as well, by
setting up the Maven POMs for OSGi bundle generation (which is a piece
of cake with the maven-bundle-plugin and maven-scr-plugin from the
Felix project).
-Bertrand
Re: microsling script resolution rewritten (was: Microsling, first shot...)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Felix,
On 10/14/07, Felix Meschberger <fm...@gmail.com> wrote:
> ...The net result of this would be that we do not just have a simple quick
> start microsling but also the basis for the full Sling....
Sounds great!
I agree with the features that you suggest for microsling - we'll
probably need to discuss some things in more detail, but for now I
think keeping both "variants" of Sling is a great idea.
-Bertrand
Re: microsling script resolution rewritten (was: Microsling, first
shot...)
Posted by Felix Meschberger <fm...@gmail.com>.
Hi all,
... Oh yeah, and this one gets lengthy, too ...
I have to agree, that microsling really grasps a majority of Sling and
may even be the PHP-programmers dream-come-true :-) Thinking about what
microsling is and where it may be positioned with respect to Sling, I
imagine, we could define microsling as the entry-level Sling and Sling
the "Big One".
As such microsling would have a MicroSlingServlet which has pretty much
everything wired and no OSGi, that is no real lifecycle management and
extensibility. Just the core request handling and scripting dispatching.
Besides this, the use of API would be the same as for the real Sling,
esp. the Resource and HttpServletRequest/Response extensions.
In short, the "features" of microsling are:
* Repository and Session acquiry: Repository is expected as
ServletContext attribute, the
credentials for the session are acquired through HTTP Basic
Authentication, if missing
either an anonymous session may be used or a 401 may sent back.
* Resource Resolution: Implementation fixed after session acquiry tries
to cut off the
URL string until a node is found. Parts of the URL not "used" by the
node node path are
set on the Resource as selectors, extension and suffix.
* Object Mapping: After Resource Resolution, the node might be mapped to
an object given
a object mapping would be implemented and a mapping would exist.
* Resource interface: Provides access to the Node (getNode()) as well as
the other parts
of the URL, such as the extension, selectors and suffix. The
optionally mapped object
is available as the resource data (getData()) of type Object. The
resource type is
derived from a special property in the node and defaults to the
primary node type
name if no such property exists.
* ScriptHandlers: Predefined map of handlers indexed by the script
extension.
* ScriptResolution: Find a script by first looking for a servlet
registered to handle
resources with the type fo the resource (in microsling there will
typically be
none). If not found, create a script path from the resource type, the
selectors and
the request method to locate a script, e.g.: scriptPath is
${scriptRoot}/${resourceType}/${selectors}/${method}.*
The resolver would get nodes and take the extension of the node(s)
found to use as the
script type (e.g. vlt or js) to index the ScriptHandlers map. If any
entry is found
the ScriptHandler is called with the script found. If none would be
found some
fallback mechanism would be implemented.
Now, to get from microsling to Sling, the MicroSlingServlet is replaced
by the SlingServlet (currently called ComponentRequestHandlerImpl ...)
but the same basic code might be used with some extensions:
* Repository Provisiong: More flexibility might be provided by making
the repository available
through some OSGi (factory) service
* Authentication: More authentication methods than just HTTP Basic may
be supported
* Resource Resolution: In addition to just taking the URL as is,
different mappings might
be supported
* ScriptHandlers: Registration of ScriptHandlers is not hard coded but
flexible through
OSGi services
* ScriptResolution: Add functionality to register Servlets for certain
resource types
The net result of this would be that we do not just have a simple quick
start microsling but also the basis for the full Sling. People starting
with microsling may easily migrate to real sling without having to touch
the scripts. And we may reuse much of the microsling code to implement
the real sling and thus reduce and prevent code duplicity.
Regards
Felix
Am Freitag, den 12.10.2007, 12:35 +0200 schrieb Bertrand Delacretaz:
> On 10/11/07, Felix Meschberger <fm...@gmail.com> wrote:
>
> > ...I am also not sure, whether script resolution according to the resource
> > path is actually a good idea...
>
> You're right, that was a bad idea...I have added a
>
> String getResourceType();
>
> method to the Resource interface, which is meant to point to a
> repository location where scripts and other definitions can be found.
>
> And rewritten the SlingScriptResolver to use this.
>
> Script names are also based on the request extension now, so for
> example if a scripting SlingServlet is looking for a script with a
> "vlt" extension:
>
> When rendering a Resource with resourceType=/some/stuff
>
> For a GET request with with URL extension=html
>
> The SlingScriptResolver looks for a script named
> /sling/scripts/some/stuff/get.html.vlt
>
> The updated microsling-homepage.html attached to
> https://issues.apache.org/jira/browse/SLING-47 contains links to
> source code for a quick code walkthrough.
>
> Do you guys think we need to add more stuff to microsling to reflect
> the core ideas of the Sling request processing? ResponseFilters maybe?
>
> -Bertrand.
Re: microsling script resolution rewritten (was: Microsling, first shot...)
Posted by Bertrand Delacretaz <bd...@apache.org>.
(note also that I'm writing microsling with a small m now - it looks
soooo bad with a capital M, reminds me of an ugly monster ;-)
-Bertrand
Re: microsling script resolution rewritten (was: Microsling, first shot...)
Posted by Tobias Bocanegra <to...@day.com>.
very good. nice summary. i agree with all of the points.
regards, toby
On 10/14/07, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Some notes regarding the current state of Script resolution: (1) The
> script is selected by the HTTP method name. So I see no reason to also
> call a ScriptHandler method of the same name. In fact, the current
> SlingServlet API pretty much limits the HTTP methods supported, which
> IMHO is not really a good idea. Rather the ScriptHandler should just
> have a single service method which is called with the request, response
> and resolved resource.
>
> (2) I am not sure whether resolving the script with the request
> extension is useful. Rather I would use the "selectors" of the request
> URL (the dot-separated parts between the node path and the extension) as
> further script selectors.
>
> Regarding the resource: I think, we should provide the JCR item to which
> the request URL resolved with a proper method, such as "Item getItem();"
> and leave the "Object getDate();" method to the object mapping. In
> addition, I would provide the selectors, extension and suffix in the
> Resource, too, as proposed on the Wiki page.
>
> Providing the JCR Item and mapped object in the Resource interface
> itself would of course stipulate, that microsling (and hence Sling, see
> my other posting in this thread) would be based on the repository and/or
> mapping and there would be no other source such as the filesystem etc.
> Of course for "synthetic" Resources, the getItem() and getData() methods
> might return null if there would be no more data than the path/URI and
> the resource type.
>
> Regards
> Felix
>
> Am Freitag, den 12.10.2007, 12:35 +0200 schrieb Bertrand Delacretaz:
> > On 10/11/07, Felix Meschberger <fm...@gmail.com> wrote:
> >
> > > ...I am also not sure, whether script resolution according to the resource
> > > path is actually a good idea...
> >
> > You're right, that was a bad idea...I have added a
> >
> > String getResourceType();
> >
> > method to the Resource interface, which is meant to point to a
> > repository location where scripts and other definitions can be found.
> >
> > And rewritten the SlingScriptResolver to use this.
> >
> > Script names are also based on the request extension now, so for
> > example if a scripting SlingServlet is looking for a script with a
> > "vlt" extension:
> >
> > When rendering a Resource with resourceType=/some/stuff
> >
> > For a GET request with with URL extension=html
> >
> > The SlingScriptResolver looks for a script named
> > /sling/scripts/some/stuff/get.html.vlt
> >
> > The updated microsling-homepage.html attached to
> > https://issues.apache.org/jira/browse/SLING-47 contains links to
> > source code for a quick code walkthrough.
> >
> > Do you guys think we need to add more stuff to microsling to reflect
> > the core ideas of the Sling request processing? ResponseFilters maybe?
> >
> > -Bertrand.
>
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: microsling script resolution rewritten (was: Microsling, first
shot...)
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Some notes regarding the current state of Script resolution: (1) The
script is selected by the HTTP method name. So I see no reason to also
call a ScriptHandler method of the same name. In fact, the current
SlingServlet API pretty much limits the HTTP methods supported, which
IMHO is not really a good idea. Rather the ScriptHandler should just
have a single service method which is called with the request, response
and resolved resource.
(2) I am not sure whether resolving the script with the request
extension is useful. Rather I would use the "selectors" of the request
URL (the dot-separated parts between the node path and the extension) as
further script selectors.
Regarding the resource: I think, we should provide the JCR item to which
the request URL resolved with a proper method, such as "Item getItem();"
and leave the "Object getDate();" method to the object mapping. In
addition, I would provide the selectors, extension and suffix in the
Resource, too, as proposed on the Wiki page.
Providing the JCR Item and mapped object in the Resource interface
itself would of course stipulate, that microsling (and hence Sling, see
my other posting in this thread) would be based on the repository and/or
mapping and there would be no other source such as the filesystem etc.
Of course for "synthetic" Resources, the getItem() and getData() methods
might return null if there would be no more data than the path/URI and
the resource type.
Regards
Felix
Am Freitag, den 12.10.2007, 12:35 +0200 schrieb Bertrand Delacretaz:
> On 10/11/07, Felix Meschberger <fm...@gmail.com> wrote:
>
> > ...I am also not sure, whether script resolution according to the resource
> > path is actually a good idea...
>
> You're right, that was a bad idea...I have added a
>
> String getResourceType();
>
> method to the Resource interface, which is meant to point to a
> repository location where scripts and other definitions can be found.
>
> And rewritten the SlingScriptResolver to use this.
>
> Script names are also based on the request extension now, so for
> example if a scripting SlingServlet is looking for a script with a
> "vlt" extension:
>
> When rendering a Resource with resourceType=/some/stuff
>
> For a GET request with with URL extension=html
>
> The SlingScriptResolver looks for a script named
> /sling/scripts/some/stuff/get.html.vlt
>
> The updated microsling-homepage.html attached to
> https://issues.apache.org/jira/browse/SLING-47 contains links to
> source code for a quick code walkthrough.
>
> Do you guys think we need to add more stuff to microsling to reflect
> the core ideas of the Sling request processing? ResponseFilters maybe?
>
> -Bertrand.