You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Torgeir Veimo (JIRA)" <ji...@apache.org> on 2007/10/17 22:46:51 UTC
[jira] Commented: (SLING-64) Refactor Servlets and Script
resolution
[ https://issues.apache.org/jira/browse/SLING-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535735 ]
Torgeir Veimo commented on SLING-64:
------------------------------------
How about abstracting this a bit, instead of relying on servlets to say themselves if they can handle a request, to use factories, or rather, mappers.
A manager would resolve a request to a sling servlet by iterating through its configured mappers and stopping once a suitable sling servlet is found. If no mapper resolves a servlet, the default sling servlet is called.
public interface ServletMapper {
public SlingServlet findServlet(SlingServletRequest request, Resource resource) throws Exception;
}
A configuration file would specify the order of the mappers, along with any configuration parameters each mapper needs. (A simple digester implementation would allow configuration parameters to be set using reflection.)
A default mapper which maps to servlets based on url and/or jcr node type or resource type can be provided which would be sufficient in most cases. For specific needs a sling api user would implement his own mapper.
Sitemesh uses a similar setup with great success for decorating web pages based on any combination of url patterns, request parameters and others. I'm using such a mapper approach successfully in our own prototype crm framework.
> Refactor Servlets and Script resolution
> ---------------------------------------
>
> Key: SLING-64
> URL: https://issues.apache.org/jira/browse/SLING-64
> Project: Sling
> Issue Type: Improvement
> Components: microsling
> Reporter: Felix Meschberger
> Fix For: 2.0.0
>
> Attachments: SLING-64.patch
>
>
> microsling currently defines a SlingServlet interface which has a canProcess method used to decide whether a servlet is capable of handling a request or not. I think, this mechanism will not scale well if we add more script engines or more servlets.
> As a first step towards a simpler approach, I propose the following:
> * Merge the DefaultSlingServlet and the SlingPostServlet to a single DefaultSlingServlet
> * Replace Rhino and Velocity servlets by respective ScriptEngines (and define the interface for that)
> * Refactor the SlingScriptResolver such that after resolving the script, it is also evaluated through a ScriptEngine
> * Refactor MicroSlingServlet such, that
> (1) check for a servlet by resource type
> (2) try to evaluate a script
> (3) fall back to the DefaultSlingServlet
> * Also in the MicroSlingServlet register servlets by type (currently there are none of course)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.