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/04 08:34:21 UTC
Re: Suggest removing the /sling/scripts prefix from script names,
and adding catch-all default scripts
Hi Bertrand,
Am Montag, den 03.12.2007, 16:57 +0100 schrieb Bertrand Delacretaz:
> Currently microsling looks for scripts under /sling/scripts, which is
> not very convenient if running several apps in the same repository:
> all scripts would end up under this path, which makes it harder to
> package applications.
Very true. The same holds for Sling for the moment.
> Here's a proposal for a different way of resolving scripts, with three
> possible cases:
>
> a) Node has a valid sling:resourceType property
> The resource type is the value of this property, which, to be valid,
> must not be empty and must start with a /.
I think, we should allow for relative paths, so no leading slash
requirement. But: If there is a leading slash, the resourceType path
would be taken as absolute. Sounds reasonable.
But, I would say, that for maximum interoperability, such paths should
be relative.
> b) Node doesn't have a valid sling:resourceType property
> In this case, the resource type is the node type, for example "nt:unstructured".
>
> To map to a script, the resource type is converted to a valid path,
> and prefixed with "/apps/sling".
Why not just /apps ?
> For an nt:unstructured node, microsling looks for scripts named
> /apps/sling/nt/unstructured/<method>.<ext>
>
> c) Script not found using either a) or b) rules
> As a catch-all default (useful mostly for tutorials and simple example
> apps), microsling looks for scripts named
> /apps/sling/default/<method>.<ext>
I do not like this catch all script. We have the default servlet to
catch all. If we have the catch all script, the default servlet will
probably never be called :-)
As a closing statement: I think it is important to clearly define
concerns. The first concern is "every resource has a resource type", the
second one is "the script path is derived from the resource type". What
is really important to me, is that the resource type is resolved before
the script is being resolved. The ScriptResolver only cares for the
Resoure.getResourceType.
So the first question is: How is the resource type defined ? I think it
is (a) the string value of the resource type property. This may be an
absolute or relative path or a namespaced name (e.g. nt:file, just like
a node type). (b) if there is no resource type property, the primary
node type name is used as the resource type.
The second question is: How to get the path from the resource type ? I
think it is the possibly modified resource type. If the resource type is
a namespaced name (that is contains one colon and no slash, such as
nt:file but not pref:name/other:name), the colon is replaced by a slash.
Otherwise the resource type is taken as a path as is.
Finally, the script is looked up below the resource type path if that
path is absolute. If the resoure type path is relative a search path
(compare to PATH environment variable) is applied. For microsling, this
may be fixed, for Sling this will be configurable.
WDYT ?
Regards
Felix
Re: Suggest removing the /sling/scripts prefix from script names,
and adding catch-all default scripts
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Hi,
>
> Am Mittwoch, den 05.12.2007, 16:11 +0100 schrieb Marcel Reutegger:
>> what's the reason to split the node type name into two path segments? please
>> keep in mind that the prefix is not stable and may be changed.
>
> To get some kind of structure into the repository for script
> organization. Otherwise the top level script directory would be
> cluttered with node type names just like the /jcr:system/jcr:nodeTypes
> node in Jackrabbit.
>
> Yes, the prefix is not stable - which has its pros and cons. But from an
> application point of view (which is what we have in case of using script
> paths), these prefixes should stay stable - Building an application
> adapting to prefix changes is close to impossible - of course we could
> use the uri as the path element instead of prefix - but I am sure, this
> is not very user friendly ...
>
And we have a mechanism in Sling which ensures that namespaces use a
well defined (configured) namespace for all sessions within Sling.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Suggest removing the /sling/scripts prefix from script names,
and adding catch-all default scripts
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Marcel,
You are correct. But I think we are acting in some kind of a grey zone:
The script is called by the application so belongs to the application
domain. Yet the script path is derived from the application view of the
node type's namespace prefix, which not necessairily is the same as the
system wide used prefix ...
There is probably only one real fix for this: use the namespace uri as
the path part, ...
Still, I think we can safely live with the current situation as
namespace remapping is not something, which should be done very often.
Unlike in XML documents, where using different prefixes for the same
namespace in different documents is absolutely no deal.
Regards
Felix
Am Freitag, den 07.12.2007, 13:11 +0100 schrieb Marcel Reutegger:
> Felix Meschberger wrote:
> > Am Freitag, den 07.12.2007, 12:02 +0100 schrieb Marcel Reutegger:
> >> the application simply has to set prefix to uri mappings on its
> >> session for the prefixes it uses.
> >
> > Which is what we do and thus have "stable" prefixes, right ?
>
> not quite. I'm probably just too picky.
>
> e.g. lets assume I create an application with a custom prefix 'mynt', then I
> later find out 'my' is a better prefix. Because my application already does the
> session remapping of 'mynt' to the namespace uri everything is fine.
>
> from an application perspective it looks as if the view on the workspace is
> consistent, but only because the application fixes the inconsistency by
> re-mapping the uri.
>
> just looking at the plain workspace the script path contains 'mynt' while the
> node type is prefixed with 'my'. The correct association can only be inferred
> from the application and not from the workspace.
>
> but as I said, I'm probably just too picky, so ignore all this...
>
> regards
> marcel
Re: Suggest removing the /sling/scripts prefix from script names,
and adding catch-all default scripts
Posted by Marcel Reutegger <ma...@day.com>.
Felix Meschberger wrote:
> Am Freitag, den 07.12.2007, 12:02 +0100 schrieb Marcel Reutegger:
>> the application simply has to set prefix to uri mappings on its
>> session for the prefixes it uses.
>
> Which is what we do and thus have "stable" prefixes, right ?
not quite. I'm probably just too picky.
e.g. lets assume I create an application with a custom prefix 'mynt', then I
later find out 'my' is a better prefix. Because my application already does the
session remapping of 'mynt' to the namespace uri everything is fine.
from an application perspective it looks as if the view on the workspace is
consistent, but only because the application fixes the inconsistency by
re-mapping the uri.
just looking at the plain workspace the script path contains 'mynt' while the
node type is prefixed with 'my'. The correct association can only be inferred
from the application and not from the workspace.
but as I said, I'm probably just too picky, so ignore all this...
regards
marcel
Re: Suggest removing the /sling/scripts prefix from script names,
and adding catch-all default scripts
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Freitag, den 07.12.2007, 12:02 +0100 schrieb Marcel Reutegger:
> > Yes, the prefix is not stable - which has its pros and cons. But from an
> > application point of view (which is what we have in case of using script
> > paths), these prefixes should stay stable - Building an application
> > adapting to prefix changes is close to impossible
>
> why is that? the application simply has to set prefix to uri mappings on its
> session for the prefixes it uses.
Which is what we do and thus have "stable" prefixes, right ?
> > - of course we could
> > use the uri as the path element instead of prefix - but I am sure, this
> > is not very user friendly ...
>
> my concern is just that this turns a prefix into a local name, which seems
> wrong.
This is kind of correct. On the other hand IIUIC namespacing is for
ordering and collision prevention, which is what we also do here.
> but on the other hand, how will ever change a prefix?
Exactly.
Regards
Felix
Re: Suggest removing the /sling/scripts prefix from script names,
and adding catch-all default scripts
Posted by Marcel Reutegger <ma...@day.com>.
Felix Meschberger wrote:
> To get some kind of structure into the repository for script
> organization.
ok, that's also what I assumed...
> Yes, the prefix is not stable - which has its pros and cons. But from an
> application point of view (which is what we have in case of using script
> paths), these prefixes should stay stable - Building an application
> adapting to prefix changes is close to impossible
why is that? the application simply has to set prefix to uri mappings on its
session for the prefixes it uses.
> - of course we could
> use the uri as the path element instead of prefix - but I am sure, this
> is not very user friendly ...
my concern is just that this turns a prefix into a local name, which seems
wrong. but on the other hand, how will ever change a prefix?
regards
marcel
Re: Suggest removing the /sling/scripts prefix from script names,
and adding catch-all default scripts
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Mittwoch, den 05.12.2007, 16:11 +0100 schrieb Marcel Reutegger:
> what's the reason to split the node type name into two path segments? please
> keep in mind that the prefix is not stable and may be changed.
To get some kind of structure into the repository for script
organization. Otherwise the top level script directory would be
cluttered with node type names just like the /jcr:system/jcr:nodeTypes
node in Jackrabbit.
Yes, the prefix is not stable - which has its pros and cons. But from an
application point of view (which is what we have in case of using script
paths), these prefixes should stay stable - Building an application
adapting to prefix changes is close to impossible - of course we could
use the uri as the path element instead of prefix - but I am sure, this
is not very user friendly ...
Regards
Felix
Re: Suggest removing the /sling/scripts prefix from script names,
and adding catch-all default scripts
Posted by Marcel Reutegger <ma...@day.com>.
Bertrand Delacretaz wrote:
> I don't really have a use case for that though, for tutorials we'll
> probably work with nt:unstructured nodes, and the scripts will be
> found under /apps/nt/unstructured, that's fine with me.
what's the reason to split the node type name into two path segments? please
keep in mind that the prefix is not stable and may be changed.
regards
marcel
Re: Suggest removing the /sling/scripts prefix from script names,
and adding catch-all default scripts
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Dienstag, den 04.12.2007, 09:24 +0100 schrieb Bertrand Delacretaz:
> ...
> > ...So the first question is: How is the resource type defined ? I think it
> > is (a) the string value of the resource type property. This may be an
> > absolute or relative path or a namespaced name (e.g. nt:file, just like
> > a node type). (b) if there is no resource type property, the primary
> > node type name is used as the resource type....
>
> ok
>
> > ..The second question is: How to get the path from the resource type ? I
> > think it is the possibly modified resource type....
>
> By "modified" you mean "cleaned up to be usable as a path", right?
Yes, by modified I mean namespaced-names converted to relative paths.
Regards
Felix
Re: Suggest removing the /sling/scripts prefix from script names, and adding catch-all default scripts
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Felix,
On Dec 4, 2007 8:34 AM, Felix Meschberger <fm...@gmail.com> wrote:
> > ...Here's a proposal for a different way of resolving scripts, with three
> > possible cases:
> >
> > a) Node has a valid sling:resourceType property
> > The resource type is the value of this property, which, to be valid,
> > must not be empty and must start with a /.
>
> I think, we should allow for relative paths, so no leading slash
> requirement. But: If there is a leading slash, the resourceType path
> would be taken as absolute. Sounds reasonable...
I was going to ask "relative to what", but you mention a search path
below, and I'm ok with that.
For microsling, the search path might be fixed to "/apps".
> > ...To map to a script, the resource type is converted to a valid path,
> > and prefixed with "/apps/sling".
>
> Why not just /apps ?...
I thought that if the nodetype is used for script resolution (because
the nodetype is the resource type in some cases, agreed), it would be
cleaner to find all "nodetype-related" scripts under /apps/sling. But
having them under /apps/nt or /apps/mynamespace is fine.
> >... c) Script not found using either a) or b) rules
> > As a catch-all default (useful mostly for tutorials and simple example
> > apps), microsling looks for scripts named
> > /apps/sling/default/<method>.<ext>
>
> I do not like this catch all script. We have the default servlet to
> catch all. If we have the catch all script, the default servlet will
> probably never be called :-)...
That's only if the catch-all script is present.
I don't really have a use case for that though, for tutorials we'll
probably work with nt:unstructured nodes, and the scripts will be
found under /apps/nt/unstructured, that's fine with me.
> ...As a closing statement: I think it is important to clearly define
> concerns. The first concern is "every resource has a resource type", the
> second one is "the script path is derived from the resource type"....
Agreed.
> ... What
> is really important to me, is that the resource type is resolved before
> the script is being resolved. The ScriptResolver only cares for the
> Resoure.getResourceType....
Sure, that's how things work now, fine with me.
> ...So the first question is: How is the resource type defined ? I think it
> is (a) the string value of the resource type property. This may be an
> absolute or relative path or a namespaced name (e.g. nt:file, just like
> a node type). (b) if there is no resource type property, the primary
> node type name is used as the resource type....
ok
> ..The second question is: How to get the path from the resource type ? I
> think it is the possibly modified resource type....
By "modified" you mean "cleaned up to be usable as a path", right?
> ... If the resource type is
> a namespaced name (that is contains one colon and no slash, such as
> nt:file but not pref:name/other:name), the colon is replaced by a slash.
> Otherwise the resource type is taken as a path as is....
ok
> ...Finally, the script is looked up below the resource type path if that
> path is absolute. If the resoure type path is relative a search path
> (compare to PATH environment variable) is applied. For microsling, this
> may be fixed, for Sling this will be configurable....
ok
-Bertrand