Hi, Am Freitag, den 26.10.2007, 16:38 +0200 schrieb Torgeir Veimo: > Some suggestions: > > 1. I still feel that the mechanism to resolve a servlet is a bit too > hard coded. I'd suggest adding a ServletResolver interface, which > would work similar to the ResourceResolver. The selectSlingServlet() > method would then resolve a Servlet using the configured > ServletResolver(s). The body of the current selectSlingServlet() > method could form a DefaultSlingServletResolver to maintain current > functionality.
Completely agree with you. Fact is that the sling-api project has a ServletResolver which works similar to the ResourceResolver and takes the Resource into account for resolving a Servlet to handle the request. The current microsling selectSlingServlet method in the main servlet is of course not the role model for the real task. > 2. Generalise the "Servlet" into a sort of "View" component. The best > analogy is probably Struts' ActionForward class. Wouldn't it be > appropriate to use a JSP as a view component for a Resource? I feel > that having the SlingMainServlet resolve to view components is > duplicating functionality available in the servlet container. A > SlingForward could either be initialised with a resource type, > requesting handling by the appropriate SlingServlet for the resource > type, by a normal path parameter to forward to a JSP decided by the > servlet container, or some other constant to request handling by a > script execution servlet. The above interface would then contain the > method This is too much overhead and in fact is one of the main concerns I have with Struts. I think the current solution of resolving the request to a Servlet (taking the Resource and other request properties (method, selectors, extension) into account is appropriate. If the response should be rendered by another Servlet (be it a normal servlet, be it a script, or whatever) may be implemented by standard request forwarding. > 3. Extend the MicroslingRequestContext implementation to resolve a > number of ResourceResolver and ServletResolver from the service > locator. They should be orderly configured, and each one tried until > one actually resolves a Resource / Servlet. This would be needed for > the suggested ServletResolver setup to be easily extended as > suggested above. I do not think, that this is appropriate for microsling. For the real Sling we might implement such feature of chained Resource- and ServletResolvers as actual requirements would raise. On the API level, I would not codify this. Regards Felix
