Re: Move ContentManager to Sling API
On Mon, 2007-10-08 at 08:22 +0200, Felix Meschberger wrote: Am Freitag, den 05.10.2007, 21:36 +0100 schrieb Torgeir Veimo: I feel it's cleaner to fetch the manager from some sort of factory instance. It wouldn't expose the implementation details of how the manager is kept local to the request, nor does it make any dependent code reliant on any such implementation details staying stable. Well, the implementation in fact is to use a factory to get the ContentManager. Look at the ContentResolverFilter class. But this is different from the question on how we provide the ContentManager to components: As the return value of a declared method or as a well known request attribute. The first solution locks the Component into the API and forces the implementation of the API itself into providing a ContentManager object. The second solution of just having the request attribute makes the existence of a ContentManager an implementation detail of the API implementation but locks the Component into the API implementation, which IMHO is more of a problem than being locked into the API. As you say yourself, you now keep the manager as a request-scoped attribute, but would like to make a subclass of HttpServletRequest include a method to retrieve it. If you used a factory to retrieve the manager, that change wouldn't have any impact on any code that uses that manager. The ContentManager is core to Sling - without the ContentManager Sling cannot operate because it is used by Sling - the ContentResolver implementation to be precise - to resolve paths to Content instances. So Sling cares to have the ContentManager handy and just provides it to components to manage the Content. Regarding extending HttpServletRequest: The ComponentRequest interface already extends the HttpServletRequest interface, so adding a getter for the ContentManager would just add to the ComponentRequest interface. I have to admit I haven't started working closely with Sling yet, so I don't have the full overview of the API yet. My concern for subclassing core interfaces in the servlet API is due to deployment and testing concerns. If you have an API where you allow users of the API to rely on there always being subclassed instances of HttpServletRequest available, then you also lock any deployment configuration into always providing it. With my experience with different servlet containers and deployment models, one cannot always ensure that specific servlet filters are handling requests at all times in a given servlet container. Eg. try getting servlet filters to work 100% of the time for error pages in tomcat. Thus, I always prefer a mechanism for retrieving manager instances which do not rely on subclassing HttpServletRequest or employing filters. The testing issue is a bit more simple, mainly concerned with making it easier to test code by using interfaces and classes that can easily be mocked. HttpServletRequest is not the best in that regard. -- -Tor
Re: Move ContentManager to Sling API
Felix Meschberger wrote:
Hi all,
Upon replying to Edgar's question regarding writing Content, I came to
thinking, that the ContentManager is a core interface of Sling and
probably should be made available more prominently. The most prominent
location for an interface in Sling would be the Sling API itself.
What do you think of moving the o.a.s.content.ContentManager interface
to the Sling API and provide it through the ComponentRequest instead of
having to access a request attribute:
public interface ComponentRequest extends HttpServletRequest {
public ContentManager getContentManager();
What do you think ? If feedback is positive, I would also include this
in the Sling API proposal (SLING-28).
I'm not sure - it definitly makes repository based components much
easier, but draws in some stuff into the (now simple) sling api and the
core. As ContentManager does not have any further dependencies this
seems to be ok.
So I'm +0 on this :)
I'm wondering if it is sufficient to have a single content manager in
the application? Or could it be that some components might use a
different content manager than others? For example some components
writing/reading from one workspace or others doing it with another
workspace?
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
Re: Move ContentManager to Sling API
On 5 Oct 2007, at 15:56, Felix Meschberger wrote:
What do you think of moving the o.a.s.content.ContentManager interface
to the Sling API and provide it through the ComponentRequest
instead of
having to access a request attribute:
public interface ComponentRequest extends HttpServletRequest {
public ContentManager getContentManager();
}
What do you think ? If feedback is positive, I would also include this
in the Sling API proposal (SLING-28).
Having done some work recently with Day Communique, one of the
annoying things was that it subclasses HttpServletRequest.
-1
--
Torgeir Veimo
[EMAIL PROTECTED]
Re: Move ContentManager to Sling API
Hi Torgeir, Am Freitag, den 05.10.2007, 17:25 +0100 schrieb Torgeir Veimo: Having done some work recently with Day Communique, one of the annoying things was that it subclasses HttpServletRequest. Can you please elaborate on this ? Because we initially did not extend HttpServletRequest but found that extending it would make the implementation much easier in multiple places not the least support for running JSP scripts. Regards Felix
Re: Move ContentManager to Sling API
On 5 Oct 2007, at 17:30, Felix Meschberger wrote: Hi Torgeir, Am Freitag, den 05.10.2007, 17:25 +0100 schrieb Torgeir Veimo: Having done some work recently with Day Communique, one of the annoying things was that it subclasses HttpServletRequest. Can you please elaborate on this ? Because we initially did not extend HttpServletRequest but found that extending it would make the implementation much easier in multiple places not the least support for running JSP scripts. I feel it's cleaner to fetch the manager from some sort of factory instance. It wouldn't expose the implementation details of how the manager is kept local to the request, nor does it make any dependent code reliant on any such implementation details staying stable. As you say yourself, you now keep the manager as a request-scoped attribute, but would like to make a subclass of HttpServletRequest include a method to retrieve it. If you used a factory to retrieve the manager, that change wouldn't have any impact on any code that uses that manager. The factory method to retrieve the manager could easily take an HttpServletRequest as parameter, which would allow you to implement it in any way you choose. -- Torgeir Veimo [EMAIL PROTECTED]
