On 27 Oct 2007, at 16:42, Felix Meschberger wrote:
Hi,
Am Freitag, den 26.10.2007, 16:38 +0200 schrieb Torgeir Veimo:
Some suggestions:
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.
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".
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?
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.
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? My preference for
such cases would be to have it in the API, since it would otherwise
require using implementation specific coding.
--
Torgeir Veimo
[EMAIL PROTECTED]
