On 29 Oct 2007, at 14:54, Bertrand Delacretaz wrote:
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.
Yes I guess the terminology is a bit confusing. A Resource is also
something used in WebDAV. But I guess the naming issue is done and
dusted already.
...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.
This is fine for new implementation. What if one need to implement
legacy services, where the url patterns used are different?
Providing the request selector as the default mechanism is good.
Having it as the only mechanism is bad.
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.
Ok, Felix also stated this clearly. My preference would be to have
only one sling, where OSGi is optional though.
--
Torgeir Veimo
[EMAIL PROTECTED]
