On 14 Jul 2009, at 13:46, Carsten Ziegeler wrote:
Ian Boston wrote:
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?
Hmm, I don't want to do this based on the path or any other "volatile"
information. I think the component that is currently creating the
synthetic resource should just always create a synthetic resource sub
class with a proper adaptTo implementation.
Creating a sub class and implementing adaptTo looks fine to me, I cant
see anywhere in the core code base where thats going to cause a problem.
AFAICT, inside the core code SyntheticResoruces are created in
1. UserManager for the various virtual stub paths.
2. RedirectResources
3. ErrorResource
4. in general in the servlet handler where the resource doesn't
resolve (eg no jcr path for a servlet)
AFAICT there are no assumptions about the behavior of a Synthetic
resource in the core code base, other than the assumption that it
doesn't point to a real resource, so if used it might require mapping
to a real JCR resource followed by a second dispatch. (I found
recursive loops when I tried to translate the resource mid resolution
process)
I haven't looked in detail
yet, where this is exactly happening.
To handle /content/blog/**/comments, AFAICT its in
JcrResourceResolver2 just after the resource fails to resolve to a
JcrNodeResource and before a NonExistentResource is created.
(but I don't know the code base as well as you do :) )
:),
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
Hmm, I think these are two different (while slightly related)
issues :)
The original issue in this thread is about having a better
implementation of adaptTo in a synthetic resource (currently it always
returns null) - this is a generic approach we could solve in one
general
place.
agreed
Your concern is more application specific and requires some kind if
plugin mechanism - I'm not against your idea, but so far I see the use
case for the first thing :)
Maybe we can come to a solution for both use cases.
agreed, a better generic adaptTo for a SyntheticResource, and then
(perhaps) using that to help represent the non existent path that a
plugin wants to control.
Ian
Carsten
--
Carsten Ziegeler
[email protected]
