Felix,
Inline:
On 25 May 2009, at 09:22, Felix Meschberger wrote:
Hi Ian,
Replying to this, though I only completely understood your request
after
reading your second post.
So what you really want is, that if a request comes in prefixed with
/_user/private/
to be redirected to
/_private/-some-path-/private/
where -some-path- is dynamic and includes the user id of the current
user. Right ?
yes, internally redirected as the /system/userManager/user/ieb does,
but, using normal content space.
This sounds similar to an earlier issue, which I recently closed
SLING-251 [1]. I closed this because it is rather old. In addition
resolving some prefix (be it "~" or "/_user/private") depends
heavily on
how "user home" locations are managed. And this is outside of the
scope
of the ResourceResolver.
I agree, user home is a jcr management/instanace deployment issue.
The use cases for this are not limited just to users, any content
tree
that is predicted to result in a URL path where there are millions of
direct children.
eg messaging inbox.
and where we don't want to expose the storage structure in the url
(ie
want inbox/231243123 not inbox/2009/01/23/12/231243123 )
and where we do not want to list the children. (except by search with
paging)
or where we simply want to abstract the binding between url and
storage.
I could imaging a plugable solution, though, in that for example we
enhance the mapping functionality of the ResourceResolver2.
Currently
there is such functionality to generate internal or external
redirects
based on configuration in /etc/map.
We could extend this such, that it would be possible to bind a
service
to such a configuration: the configuration value is an OSGi filter
expression to be used with the
BundleContext.getServiceReference(String
name, String filter) method.
In addition a service interface would be defined:
public interface MappingResolver {
ResultType resolve(HttpServletRequest, String);
ResultType map(HttpServletRequest, String);
}
Configuration would be
/etc/map/http/myhost/~
-> sling:mapper = "(prefix='~')"
This would use the MappingResolver service registered with a
registration property "prefix" set to "~".
This would allow you to register a MappingResolver service for
/_user/private and have it called to resolve requests to /_user/
private
and also to have it called for creating the URL when calling the
ResourceResolver.map method.
WDYT ?
Yes I think that would do it, and provide a simpler extension point.
In the end I have created a VirtualResource and
AbstractVirturalResourceProvider[1] that make it possible for
ResourceResolvers to wrap any other resolved Resource, the only bit I
wasn't getting was to ensure that the VirtualResource did not have
its
RequestPathInfo re computed.
Obviously the advantage of the Resource approach is ( I think, not
tested) that the ResourceProvider can bind to a resourceType
anywhere in
the content system, the advantage of the /etc/map approach is that it
can be configured at runtime.
I suspect I am going to want more flexibility in the re-writer so
would
be happy to help. Some of our sys admins love httpd mod_rewrite and
will
pounce on that level of functionality.
Would you make all of the /etc/map resolution go through the plugin
interface by making the existing code implement that interface?
