On 14 Jul 2009, at 12:51, Bertrand Delacretaz wrote:
Hi,
On Tue, Jul 14, 2009 at 1:39 PM, Carsten
Ziegeler<[email protected]> wrote:
Felix Meschberger wrote:
(5) Move the o.a.s.api.adapter package to the Sling Adapter module
(which also contains the AdapterManager implementation and the
SlingAdaptable class. Thus the Sling Adapter module would not import
from the Sling API anymore. Instead the Sling API would import
from the
Sling Adapter Module. As a consequence the SyntheticResource could
extend the SlingAdaptable class.
i think we should keep the API self contained and try to not depend
on
other parts.
On the other hand I agree that there might be use cases where
adapting a
synthetic resource makes sense....
Agreed
... So what about leaving everything as is and return where
appropriate sub
classes of SyntheticResource which have a proper adaptTo()
implementation....
Sounds good to me, but how would one do that in practice?
Say I want to return my own SyntheticResource subclass for nonexisting
paths that look like /content/blog/**/comments, how would I do that?
:),
I think I asked something similar a few weeks back.
There is a patch that changes the JcrResourceResolver2 to allow
plugins to generate ResourceTypes for non existent paths, however the
patch isn't really acceptable since it make NonExistentResource non
final. I have been thinking that instead it should be doing something
with SyntheticResource since thats what NonExistentResource extends.
Perhaps the point at which JcrResourceResolver2 generates the
NonExistentResource, plugin implementations should be given the chance
to create a SyntheticResource, around line 237 of
JcrResourceResolver2.java
To do it *without* a patch,
create a servlet that binds to sling/nonexistant and re-dispatch, but
that adds ms to the request.
Ian
-Bertrand
