You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@gmail.com> on 2007/12/10 11:07:48 UTC
Re: use case: resolving a resource based on anode´s version
Hi Juanjo,
This is a very good question, we deliberatly did not touch yet. But you
are of course right, we probably need something like this. Out of my
belly, I would think of the following:
(1) encode the requested version as part of the URL, such as
/content/some/resource.html;v=1.0 (for the resolve(request) method)
The value of the v parameter is the version label.
(2) add getResource parameters with an additional version label
parameter:
ResourceResolver.getResource(String path, String versionLabel);
(3) add support for a well-known HTTP header and/or parameter for the
ResourceResolver.resolve(request) method.
WDYT ?
Regards
Felix
Am Montag, den 10.12.2007, 11:00 +0100 schrieb Juanjo Vázquez:
> Hi all,
>
> I don´nt know if anyone has thought in this scenario: to retrieve a resource
> based on a particular version of a node instead of the head version.
>
> WDYT?
>
> Regards,
>
> Juanjo.
Re: use case: resolving a resource based on a node´s version
Posted by Michael Marth <mm...@day.com>.
>
> Do people think we need a syntax for selectors that are handled by the
> Sling/microsling framework and not by applications?
>
>
Yes.
(out-of-box handling of versions is one of the big selling points of JCRs
IMHO. It should be easy to select node versions in microsling)
--
Michael Marth, http://dev.day.com
Re: use case: resolving a resource based on a node´s version
Posted by Tobias Bocanegra <to...@day.com>.
> BTW, I find the "/content" prefix really annoying. Does anyone
> (aside from day.com) do that in real life? Most sites use virtual
> hosts for that type of separation, or at least very short roots.
the '/content' is usually hidden by rewriting filters by the server.
but for educational reasons is good to include it in discussions.
btw: public sites powered by day never have a '/content' (or should at
least not :-)
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: use case: resolving a resource based on a node´s version
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Dec 13, 2007 3:13 AM, Roy T. Fielding <fi...@gbiv.com> wrote:
> On Dec 12, 2007, at 1:10 PM, Bertrand Delacretaz wrote:
> > How about
> >
> > /content/some/resource.html/s:version:1.4/s:lang:fr/somefile.pdf
> >
> > where suffixes starting with s: are reserved for Sling usage?
>
> yuck. A general principle of web design is that you shouldn't
> be able to tell how a server is implemented by looking at the URI,...
Right...I had this vague feeling that my example URLs started to look
like...no I'm not telling what, but something ugly ;-)
> ...What we should do is separate the mapping into a sequence
> of extensibility hooks and only define the delegation points.
> For example, we know that the path up to the last JCR node
> is handled by Sling, so just define everything after that
> point (i.e., EXTRA_PATH) as input to a sequence of registered
> filters for that resource (where the sequence is itself a
> node identified by a property on the resource node, either
> explicitly or by default based on node type)...
Ok, we can reuse the existing sling:resourceType property, which
currently points to a path where processing scripts are found: that
path could contain a node that defines this sequence of filters.
> ..That would
> allow both fine-grained handling of the extra path and
> flexibility for legacy resources...
Ok - that means having some additional info (besides scripts) in the
directory pointed to by sling:resourceType, and nothing prevents this
in the current design.
IIUC this means we don't need to do anything unless someone needs
access to specific versions, as Juanjo suggests: we could then
implement a mechanism like you propose, but we already have the
"suffix acquisition" and "resource points to a configuration/script
area" parts, so we should be fine.
-Bertrand
Re: use case: resolving a resource based on a node´s version
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Dec 12, 2007, at 1:10 PM, Bertrand Delacretaz wrote:
> How about
>
> /content/some/resource.html/s:version:1.4/s:lang:fr/somefile.pdf
>
> where suffixes starting with s: are reserved for Sling usage?
yuck. A general principle of web design is that you shouldn't
be able to tell how a server is implemented by looking at the URI,
because that means the URIs will break when the implementation
is changed. A corollary is that any new web framework should be
able to adopt any existing set of resources, without the user
being aware of it and without changing the cool URIs.
What we should do is separate the mapping into a sequence
of extensibility hooks and only define the delegation points.
For example, we know that the path up to the last JCR node
is handled by Sling, so just define everything after that
point (i.e., EXTRA_PATH) as input to a sequence of registered
filters for that resource (where the sequence is itself a
node identified by a property on the resource node, either
explicitly or by default based on node type). That would
allow both fine-grained handling of the extra path and
flexibility for legacy resources.
BTW, I find the "/content" prefix really annoying. Does anyone
(aside from day.com) do that in real life? Most sites use virtual
hosts for that type of separation, or at least very short roots.
....Roy
Re: use case: resolving a resource based on a node´s version
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
> i think that our url processing is complicated enough and i
> would really like to delegate everything beyond what we have
> now to the application, until we find a usecase that is not
> served well by delegating this kind of functionality to the
> application.
You have convinced me. Definitely, complicating the url processing is a
dangerous trend.
BR,
Juanjo.
On Dec 12, 2007 11:14 PM, David Nuescheler <da...@day.com> wrote:
> hi guys,
>
> i would rather stay away from all that business and just let the
> application
> handle it. it is important to understand that for versioning jcr does
> not have the concept of a head version but the concept of a node
> in that particular workspace. so different people can already have
> different views on the same content just using different workspaces.
>
> the cases where someone wants to view or diff special versions
> in my can easily be delegated to the application and in my mind
> does not need to be a first level concept in sling.
>
> i would really like to stay away from all the locale since
> i find that i would not even like to model that on to the
> individual resource in my applications, since i want the tree to
> diverge in different locales.
>
> i think that our url processing is complicated enough and i
> would really like to delegate everything beyond what we have
> now to the application, until we find a usecase that is not
> served well by delegating this kind of functionality to the
> application.
>
> regards,
> david
>
>
> On 12/12/07, Bertrand Delacretaz <bd...@apache.org> wrote:
> > On Dec 12, 2007 6:27 PM, Juan José Vázquez Delgado
> > <ju...@gmail.com> wrote:
> >
> > > ...it´s more natural for me to have
> > >
> > > /content/some/resource.html/version1/lang1
> > > than
> > > /content/mytext.a4.print.s:version:1:4.s:locale:fr_CH.html
> > > ...
> >
> > I agree that your suggestion looks nicer (also because you have
> > simpler values that might not reflect reality ;-), and that means we
> > don't "invade" the selectors space which is good.
> >
> > I'd still like to define a syntax to differentiate suffixes that are
> > handled by Sling/microsling, as opposed to suffixes used by
> > applications.
> >
> > How about
> >
> > /content/some/resource.html/s:version:1.4/s:lang:fr/somefile.pdf
> >
> > where suffixes starting with s: are reserved for Sling usage?
> >
> > -Bertrand
> >
>
Re: use case: resolving a resource based on a node´s version
Posted by David Nuescheler <da...@day.com>.
hi guys,
i would rather stay away from all that business and just let the application
handle it. it is important to understand that for versioning jcr does
not have the concept of a head version but the concept of a node
in that particular workspace. so different people can already have
different views on the same content just using different workspaces.
the cases where someone wants to view or diff special versions
in my can easily be delegated to the application and in my mind
does not need to be a first level concept in sling.
i would really like to stay away from all the locale since
i find that i would not even like to model that on to the
individual resource in my applications, since i want the tree to
diverge in different locales.
i think that our url processing is complicated enough and i
would really like to delegate everything beyond what we have
now to the application, until we find a usecase that is not
served well by delegating this kind of functionality to the
application.
regards,
david
On 12/12/07, Bertrand Delacretaz <bd...@apache.org> wrote:
> On Dec 12, 2007 6:27 PM, Juan José Vázquez Delgado
> <ju...@gmail.com> wrote:
>
> > ...it´s more natural for me to have
> >
> > /content/some/resource.html/version1/lang1
> > than
> > /content/mytext.a4.print.s:version:1:4.s:locale:fr_CH.html
> > ...
>
> I agree that your suggestion looks nicer (also because you have
> simpler values that might not reflect reality ;-), and that means we
> don't "invade" the selectors space which is good.
>
> I'd still like to define a syntax to differentiate suffixes that are
> handled by Sling/microsling, as opposed to suffixes used by
> applications.
>
> How about
>
> /content/some/resource.html/s:version:1.4/s:lang:fr/somefile.pdf
>
> where suffixes starting with s: are reserved for Sling usage?
>
> -Bertrand
>
Re: use case: resolving a resource based on a node´s version
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Dec 12, 2007 6:27 PM, Juan José Vázquez Delgado
<ju...@gmail.com> wrote:
> ...it´s more natural for me to have
>
> /content/some/resource.html/version1/lang1
> than
> /content/mytext.a4.print.s:version:1:4.s:locale:fr_CH.html
> ...
I agree that your suggestion looks nicer (also because you have
simpler values that might not reflect reality ;-), and that means we
don't "invade" the selectors space which is good.
I'd still like to define a syntax to differentiate suffixes that are
handled by Sling/microsling, as opposed to suffixes used by
applications.
How about
/content/some/resource.html/s:version:1.4/s:lang:fr/somefile.pdf
where suffixes starting with s: are reserved for Sling usage?
-Bertrand
Re: use case: resolving a resource based on a node´s version
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
Hi,
> Do people think we need a syntax for selectors that are handled by the
> Sling/microsling framework and not by applications?
I´m not sure about using selectors instead suffixes. IMHO, version and
translations are perspectives or different angles of the same hypothetical
resource. And the name of the resource would be the "partner" of the
extension.
If you think about resources in a semantic way [1], it´s clear that we
should no understanding two different versions of the same "resource" as two
different resources.
In this way, it´s more natural for me to have
/content/some/resource.html/version1/lang1
than
/content/mytext.a4.print.s:version:1:4.s:locale:fr_CH.html
WDYT?,
BR,
Juanjo
[1] http://www.w3.org/TR/rdf-primer/
On Dec 12, 2007 4:10 PM, Bertrand Delacretaz <bd...@apache.org> wrote:
> On Dec 10, 2007 12:25 PM, Juan José Vázquez Delgado
> <ju...@gmail.com> wrote:
>
> > > (1) encode the requested version as part of the URL, such as
> > > /content/some/resource.html;v=1.0 (for the resolve(request) method)...
> >
> > ...IMHO, there are some situations which we can need to retrieve the
> same
> > resource based on a particular perspective: version, language, anything
> > else?
>
> I think that's what selectors are for - maybe we need to reserve some
> of the selector "namespace" for sling-specific stuff?
>
> For example
>
> /content/mytext.a4.print.s:version:1:4.s:locale:fr_CH.html
>
> would mean
>
> resource path = /content/mytext
> application selectors = a4.print
> version = 1.4
> locale = fr_CH
> output format = html
>
> As you mention, requesting a version in this way would need encoding
> the dots in version numbers as colons, as dots separate selectors.
>
> Do people think we need a syntax for selectors that are handled by the
> Sling/microsling framework and not by applications?
>
> -Bertrand
>
Re: use case: resolving a resource based on a node´s version
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Dec 10, 2007 12:25 PM, Juan José Vázquez Delgado
<ju...@gmail.com> wrote:
> > (1) encode the requested version as part of the URL, such as
> > /content/some/resource.html;v=1.0 (for the resolve(request) method)...
>
> ...IMHO, there are some situations which we can need to retrieve the same
> resource based on a particular perspective: version, language, anything
> else?
I think that's what selectors are for - maybe we need to reserve some
of the selector "namespace" for sling-specific stuff?
For example
/content/mytext.a4.print.s:version:1:4.s:locale:fr_CH.html
would mean
resource path = /content/mytext
application selectors = a4.print
version = 1.4
locale = fr_CH
output format = html
As you mention, requesting a version in this way would need encoding
the dots in version numbers as colons, as dots separate selectors.
Do people think we need a syntax for selectors that are handled by the
Sling/microsling framework and not by applications?
-Bertrand
Re: use case: resolving a resource based on a node´s version
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
Hi,
> (1) encode the requested version as part of the URL, such as
> /content/some/resource.html;v=1.0 (for the resolve(request) method)
I like this solution but why not to use Sling api standars like selectors or
suffixes? Really, the selectors have a problem with the dot character...
I´m not sure about the second and third propossals. I think this sort of
issue, like the version one, is not an isolated issue. For instance, what
about a resource with several translations?.
IMHO, there are some situations which we can need to retrieve the same
resource based on a particular perspective: version, language, anything
else?
BR,
Juanjo
On Dec 10, 2007 11:07 AM, Felix Meschberger <fm...@gmail.com> wrote:
> Hi Juanjo,
>
> This is a very good question, we deliberatly did not touch yet. But you
> are of course right, we probably need something like this. Out of my
> belly, I would think of the following:
>
> (1) encode the requested version as part of the URL, such as
>
> /content/some/resource.html;v=1.0 (for the resolve(request) method)
>
> The value of the v parameter is the version label.
>
> (2) add getResource parameters with an additional version label
> parameter:
>
> ResourceResolver.getResource(String path, String versionLabel);
>
> (3) add support for a well-known HTTP header and/or parameter for the
> ResourceResolver.resolve(request) method.
>
> WDYT ?
>
> Regards
> Felix
>
> Am Montag, den 10.12.2007, 11:00 +0100 schrieb Juanjo Vázquez:
> > Hi all,
> >
> > I don´nt know if anyone has thought in this scenario: to retrieve a
> resource
> > based on a particular version of a node instead of the head version.
> >
> > WDYT?
> >
> > Regards,
> >
> > Juanjo.
>
>