Hi Torgeir, On 10/29/07, Torgeir Veimo <[EMAIL PROTECTED]> wrote: > >> ...2. Generalise the "Servlet" into a sort of "View" component. The best > >> analogy is probably Struts' ActionForward class....
> ...My main concern is that I'm interested in seeing model resolution and > view resolution separated. I guess with the current framework, model > resolution is opaque to Sling, and the Resource component represents > the "view".... Not sure what you mean by "Resource component". In microsling (which drives the Sling API redesign), Components are gone, there's only -The Resource, which represents, in its simplest form, a JCR Node -The Servlet (or script) which handles the request So, although MVC does not really apply here, If we want to think in MVC terms I'd say the Resource is the Model, and the Servlet is the view (in the case of a GET method), or the controller (in the case of a POST/PUT/DELETE/unsafe) method. If we follow this reasoning, you'd handle a POST request by having microsling call a first "controller" script that manipulates data, and forwards to a GET request which calls the "view" script. Does that make sense to you? I think working in this way might help people embrace the REST style, which is IMHO a nice side effect. > ...A better example than in my previous message is a blog. Ideally, the > model for the blog would be loaded first. Then, depending on the view > being RSS or normal HTML view, a view resolver would direct to the > correct Servlet. With the current framework, a single component would > be needed for both RSS and normal view?... If by component you mean a microsling Servlet/Script, then the answer is no: the request selectors (.rss.xml) or extension (.rss) will cause a different rendering script to be used. > >> 3. Extend the MicroslingRequestContext implementation to resolve a > >> number of ResourceResolver and ServletResolver from the service > >> locator.... > ...The reason for this is to facilitate overriding the default resolver. > How would you do that in a situation where you need only a few > special cases, but otherwise the default behaviour?... I think we all agree on that for Sling, but do we want this in microsling, and if yes how do we implement that cleanly? The easiest thing that comes to mind is a composite pattern: as seen from the API, there's only one ResourceResolver, but internally that ResourceResolver can use a chain of ResourceResolvers. -Bertrand
