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 <[EMAIL PROTECTED]> 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.
