Re: [jira] Commented: (SLING-64) Refactor Servlets and Script resolution

2007-10-18 Thread Bertrand Delacretaz
On 10/18/07, Carsten Ziegeler [EMAIL PROTECTED] wrote:
 ..Sorry for trying hard to be a pita :) but again, can we please let all
 these discussions take place in the mailing list?...

You're right, sorry about that. We should discuss things here, and
move to Jira once we reach consensus.

-Bertrand


Re: [jira] Commented: (SLING-64) Refactor Servlets and Script resolution

2007-10-18 Thread Torgeir Veimo


On 18 Oct 2007, at 07:59, Carsten Ziegeler wrote:


Sorry for trying hard to be a pita :) but again, can we please let all
these discussions take place in the mailing list?
I think it's easy to first discuss a topic in the mailing list and  
then

create a jira which either sums up the discussion or references the
mailing list archives.


Ok, here is my proposal from the Jira issue comment:

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.



--
Torgeir Veimo
[EMAIL PROTECTED]