On 10/27/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Am Freitag, den 26.10.2007, 16:38 +0200 schrieb Torgeir Veimo: > >... 2. Generalise the "Servlet" into a sort of "View" component. The best > > analogy is probably Struts' ActionForward class...
> ...This is too much overhead and in fact is one of the main concerns I have > with Struts. ... > ...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... I see your point, but I have also this vague feeling that microsling and the Sling API could better separate (or maybe just better expose) the "processing" and "rendering" phases of a request. Felix, how would you suggest implementing a POST script that renders data when done processing? Do a request forwarding at the end of the POST script? That might be ok, but the programmer might want to specify exactly which rendering script they want to use after the POST, so some short-circuit of the standard Resource/SlingScript resolution might be needed. WDYT? > >... 3. Extend the MicroslingRequestContext implementation to resolve a > > number of ResourceResolver and ServletResolver from the service > > locator... > I do not think, that this is appropriate for microsling... Dunno...Torgeir, if you need this in microsling, and if you can provide simple code to implement it, I'd be +1 on putting this in microsling. But I agree with Felix that not having this in microsling still allows Sling to have that, based on OSGi "plugins".. -Bertrand
