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. Regards Felix
