Simplifying script paths and names?

classic Classic list List threaded Threaded
55 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Tobias Bocanegra
hi,
i just want to add, that most of the requests that actually hit sling
will probably be plain .html requests with no selectors. so the
/apps/foo/foo.jsp will probably resolve those requests. since requests
that usually need selectors are image requests which are very good
cacheable in a higher teer. so i don't think that in a real-live
scenario, the resource resolution performance is that relevant. and of
course it can easily be cached.

--
toby


On 4/18/08, Carsten Ziegeler <[hidden email]> wrote:

> Felix Meschberger wote:
>
>
> > Hi,
> >
> > Am Freitag, den 18.04.2008, 16:35 +0200 schrieb Carsten Ziegeler:
> >
> > > Having scripts in /apps and /libs where /libs has precendence of /apps
> still feels not very intuitive for me.
> > >
> >
> > It is the other way around: /apps has precedence over /libs. And this is
> > IMHO intuitive.
> >
> >
>  Hehe, you see, it's not intuitive for me (ok, I'll write down 100 times
> "apps has precedence over libs, apps has precedence over libs..."
>
>
>  Carsten
>
>  --
>  Carsten Ziegeler
>  [hidden email]
>

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

David Nuescheler-3
hi guys,

after going through this entire discussion and looking at issue:
https://issues.apache.org/jira/browse/SLING-387
i would like to raise the following point.

i think it is important that this change was originally suggested to
make the simple cases as simple and intuitive as possible for
the user of sling and not to come up with something that is really
easy and consistent to map for the sling implementation.

let me try to explain with an example:
as a user of sling i would like to have my app in
/apps/myapp and lets say i have a node of resourceType
"myapp/homepage" at "/content/myapp".

i would like to to be able to structure my applications as follows:

(1) /apps/myapp/homepage/hompage.esp (or html.esp or GET.esp)
(2) /apps/myapp/homepage/edit.esp (or edit.html.esp)
(3) /apps/myapp/homepage/header/highlight.jpg.esp
(4) /apps/myapp/homepage/header/selected.jpg.esp
(5) /apps/myapp/homepage/header/small.jpg.esp

where

/content/myapp.html -> (1)
/content/myapp.edit.html -> (2)
/content/myapp.header.highlight.jpg -> (3)
/content/myapp.header.selected.jpg -> (4)
/content/myapp.header.small.jpg -> (5)

i think it is important that we avoid unnecessary repetition at any point
and we would allow for enough flexibility in the /apps directory allow
the user to come up with something short, distinct and meaningful.

regards,
david





On Fri, Apr 18, 2008 at 6:34 PM, Tobias Bocanegra
<[hidden email]> wrote:

> hi,
>  i just want to add, that most of the requests that actually hit sling
>  will probably be plain .html requests with no selectors. so the
>  /apps/foo/foo.jsp will probably resolve those requests. since requests
>  that usually need selectors are image requests which are very good
>  cacheable in a higher teer. so i don't think that in a real-live
>  scenario, the resource resolution performance is that relevant. and of
>  course it can easily be cached.
>
>  --
>  toby
>
>
>
>
>  On 4/18/08, Carsten Ziegeler <[hidden email]> wrote:
>  > Felix Meschberger wote:
>  >
>  >
>  > > Hi,
>  > >
>  > > Am Freitag, den 18.04.2008, 16:35 +0200 schrieb Carsten Ziegeler:
>  > >
>  > > > Having scripts in /apps and /libs where /libs has precendence of /apps
>  > still feels not very intuitive for me.
>  > > >
>  > >
>  > > It is the other way around: /apps has precedence over /libs. And this is
>  > > IMHO intuitive.
>  > >
>  > >
>  >  Hehe, you see, it's not intuitive for me (ok, I'll write down 100 times
>  > "apps has precedence over libs, apps has precedence over libs..."
>  >
>  >
>  >  Carsten
>  >
>  >  --
>  >  Carsten Ziegeler
>  >  [hidden email]
>  >
>



--
Visit: http://dev.day.com/ - Day JCR Cup 08 - Win a MacBook Pro

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Felix Meschberger-2
Hi,

Am Freitag, den 25.04.2008, 16:40 +0200 schrieb David Nuescheler:
> after going through this entire discussion and looking at issue:
> https://issues.apache.org/jira/browse/SLING-387
> i would like to raise the following point.
>
> i think it is important that this change was originally suggested to
> make the simple cases as simple and intuitive as possible for
> the user of sling and not to come up with something that is really
> easy and consistent to map for the sling implementation.

I partially agree: But a simple implementation tends to be simpler to
explain and thus simpler to use.

> let me try to explain with an example:
> as a user of sling i would like to have my app in
> /apps/myapp and lets say i have a node of resourceType
> "myapp/homepage" at "/content/myapp".
>
> i would like to to be able to structure my applications as follows:
>
> (1) /apps/myapp/homepage/hompage.esp (or html.esp or GET.esp)
> (2) /apps/myapp/homepage/edit.esp (or edit.html.esp)
> (3) /apps/myapp/homepage/header/highlight.jpg.esp
> (4) /apps/myapp/homepage/header/selected.jpg.esp
> (5) /apps/myapp/homepage/header/small.jpg.esp
>
> where
>
> /content/myapp.html -> (1)
> /content/myapp.edit.html -> (2)
> /content/myapp.header.highlight.jpg -> (3)
> /content/myapp.header.selected.jpg -> (4)
> /content/myapp.header.small.jpg -> (5)
>
> i think it is important that we avoid unnecessary repetition at any point
> and we would allow for enough flexibility in the /apps directory allow
> the user to come up with something short, distinct and meaningful.

That sounds clear at first sight. But it amounts to a whole lot of work
to implement. This also means a whole lot of CPU to burn. And a whole
lot of code means a whole lot of potential bugs ;-)

I also wonder, why "/apps/myapp/homepage/header/highlight.jpg.esp" would
be easier to use than "/apps/myapp/homepage/header.highlight.jpg.esp" ?
It is eaven easier to manage: no need to move files in the hierarchy,
just rename them. And it is easier to explain: Instead of saying "build
a path from the selector by replacing dots by slashes" we just say
"append or use the selectors".

Therefore, I honestly consider the current proposal superior to using
paths.

Any more Opinions out there ?

Regards
Felix


Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Tobias Bocanegra
> > after going through this entire discussion and looking at issue:
>  > https://issues.apache.org/jira/browse/SLING-387
>  > i would like to raise the following point.
>  >
>  > i think it is important that this change was originally suggested to
>  > make the simple cases as simple and intuitive as possible for
>  > the user of sling and not to come up with something that is really
>  > easy and consistent to map for the sling implementation.
>
>
> I partially agree: But a simple implementation tends to be simpler to
>  explain and thus simpler to use.
>
>
>  > let me try to explain with an example:
>  > as a user of sling i would like to have my app in
>  > /apps/myapp and lets say i have a node of resourceType
>  > "myapp/homepage" at "/content/myapp".
>  >
>  > i would like to to be able to structure my applications as follows:
>  >
>  > (1) /apps/myapp/homepage/hompage.esp (or html.esp or GET.esp)
>  > (2) /apps/myapp/homepage/edit.esp (or edit.html.esp)
>  > (3) /apps/myapp/homepage/header/highlight.jpg.esp
>  > (4) /apps/myapp/homepage/header/selected.jpg.esp
>  > (5) /apps/myapp/homepage/header/small.jpg.esp
>  >
>  > where
>  >
>  > /content/myapp.html -> (1)
>  > /content/myapp.edit.html -> (2)
>  > /content/myapp.header.highlight.jpg -> (3)
>  > /content/myapp.header.selected.jpg -> (4)
>  > /content/myapp.header.small.jpg -> (5)
>  >
>  > i think it is important that we avoid unnecessary repetition at any point
>  > and we would allow for enough flexibility in the /apps directory allow
>  > the user to come up with something short, distinct and meaningful.
>
>
> That sounds clear at first sight. But it amounts to a whole lot of work
>  to implement. This also means a whole lot of CPU to burn. And a whole
>  lot of code means a whole lot of potential bugs ;-)
>
>  I also wonder, why "/apps/myapp/homepage/header/highlight.jpg.esp" would
>  be easier to use than "/apps/myapp/homepage/header.highlight.jpg.esp" ?
>  It is eaven easier to manage: no need to move files in the hierarchy,
>  just rename them. And it is easier to explain: Instead of saying "build
>  a path from the selector by replacing dots by slashes" we just say
>  "append or use the selectors".
>
>  Therefore, I honestly consider the current proposal superior to using
>  paths.
almost....i have a real usecase where i prefer a 'directory' over a
selector. in case of a 'navigation' image, i want to put additional
resources and scripts in an own directory, so currently i do:

/apps/myapp/page/nav/png.jsp   (generates the  png)
/apps/myapp/page/nav/background.jpg  (used by the above script as background)
/apps/myapp/page/nav/html.jsp  (used to dump the <img ... /> tag)

if i only can use selectors, this becomes awkward and even messy if i
have a lot of "selections".

IMO, the initial concern for the current resolution was that all
scripts were named "html.jsp" and that this is very annoying during
development.

i suggest only to change that the scripts "may" repeat the last part
of the resource type, eg:
/apps/myapp/page/page.jsp or
/apps/myapp/page/nav/nav.png.jsp

--
toby

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Dominik Süß
In reply to this post by Felix Meschberger-2
Hi,

On Fri, Apr 25, 2008 at 5:52 PM, Felix Meschberger <[hidden email]>
wrote:

> I also wonder, why "/apps/myapp/homepage/header/highlight.jpg.esp" would
> be easier to use than "/apps/myapp/homepage/header.highlight.jpg.esp" ?
> It is eaven easier to manage: no need to move files in the hierarchy,
> just rename them. And it is easier to explain: Instead of saying "build
> a path from the selector by replacing dots by slashes" we just say
> "append or use the selectors".
>
> Therefore, I honestly consider the current proposal superior to using
> paths.
>
> Any more Opinions out there ?


I'm not sure which option feels more comfortable to me.
On the one hand selectors are nice to use if you just have a few aspects of
a resource. Building a new aspect is just duplicate, rename and change the
code.
But on the other hand as soon as the amount of aspects increase it may be a
long list of scripts and this may become not so easy to manage for
refactoring.
Refactoring also may be painful if you have to rename a lot of scripts
instead of the parent node.
Duplicating the whole set of scripts also would also be much easier.
As soon as there is a hierachy in the aspects of a resource I absolutely
perfer to have a path instead of a bunch of scripts with related names.

>From a hierarchical view this could look like this:

/apps/myapp/homepage/header/jpg.esp  (or header/header.jpg.esp)
/apps/myapp/homepage/header/highlight/jpg.esp (or
highlight/highlight.jpg.esp)
/apps/myapp/homepage/header/selected/jpg.esp (or selected/selected.jpg.esp)
/apps/myapp/homepage/header/small/jpg.esp (or small/small.jpg.esp)

So in the end I tend to prefer the path.

Best regards,
Dominik
Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Dominik Süß
I missed an important point in this scenario.
The "path"option doesn't produce unique paths.

/apps/myapp/homepage/header/highlight/highlight.jpg.esp

could be a produced by resolving:
/content/myapp/homepage/header.highlight.jpg
as well as by resolving:
/content/myapp/homepage/header/highlight.jpg

Therefore  it should be up to the contenthierarchy to define these
hierarchical structures.

So dots should remain dots.

Regards,
Dominik
Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Carsten Ziegeler
It seems that the longer we discuss the more possible suggestions we get
- that's not bad per se, but I start to wonder how we can reach
consensus on this?

Now, I personally like the suggestion as outlined by Felix in the Jira
issue (using dots instead of paths), but on the other hand I agree with
Tobi that this might be bad for putting resources near the script.

Well, on the other hand, it has been pointed out that the real issue is
just the fact that all scripts are named "htlm.*". I'm really not very
optimistic that the simple looking solution to duplicate the node name
(or whatever makes up the last node in the hierarchy) to get the file
name is a clear and simple concept. Telling people that they can write
"foo.jsp" to get html while they have to use "pdf.jsp" to get a pdf,
seems very complicated to explain and understand. And as I pointed out,
as soon as you are heavily using any other format than html, you end up
with the same mess (all files named pdf.*)

So how do we want to proceed?

Carsten
--
Carsten Ziegeler
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Tobias Bocanegra
how about that you may prefix the html.jsp (or pdf.jsp) with the last
part of the resource path?

so foo.html.jsp is ok, but foo.html is not. allowing only this
addition to circumvent the IDE problems is pretty easy to understand.

--
toby

On 4/26/08, Carsten Ziegeler <[hidden email]> wrote:

> It seems that the longer we discuss the more possible suggestions we get -
> that's not bad per se, but I start to wonder how we can reach consensus on
> this?
>
>  Now, I personally like the suggestion as outlined by Felix in the Jira
> issue (using dots instead of paths), but on the other hand I agree with Tobi
> that this might be bad for putting resources near the script.
>
>  Well, on the other hand, it has been pointed out that the real issue is
> just the fact that all scripts are named "htlm.*". I'm really not very
> optimistic that the simple looking solution to duplicate the node name (or
> whatever makes up the last node in the hierarchy) to get the file name is a
> clear and simple concept. Telling people that they can write "foo.jsp" to
> get html while they have to use "pdf.jsp" to get a pdf, seems very
> complicated to explain and understand. And as I pointed out, as soon as you
> are heavily using any other format than html, you end up with the same mess
> (all files named pdf.*)
>
>  So how do we want to proceed?
>
>
>  Carsten
>  --
>  Carsten Ziegeler
>  [hidden email]
>

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Dominik Süß
In reply to this post by Carsten Ziegeler
On Sat, Apr 26, 2008 at 7:16 PM, Carsten Ziegeler <[hidden email]>
wrote:

>
> Well, on the other hand, it has been pointed out that the real issue is
> just the fact that all scripts are named "htlm.*". I'm really not very
> optimistic that the simple looking solution to duplicate the node name (or
> whatever makes up the last node in the hierarchy) to get the file name is a
> clear and simple concept. Telling people that they can write "foo.jsp" to
> get html while they have to use "pdf.jsp" to get a pdf, seems very
> complicated to explain and understand. And as I pointed out, as soon as you
> are heavily using any other format than html, you end up with the same mess
> (all files named pdf.*)
>

I did think a bit about the refactoring and renaming problems that might
occur when using prefixes. Since this is a restless architecture it might be
necessary to replicate at least the script which is calling the script which
is needed by both resources. This is pretty easy when having the scripts
named the same way (no prefixes). Having a prefix would require renaming, as
well as renaming the parent node would require changing the prefix. (which
would break the default refactoring features for renaming in Eclipse)

Propably it is usefull to remember that a script is never identified simply
by its name but additionaly the path. So the name does never identify the
script (which script is called?) but identfies under which circumstances it
is called(when is it called?).

It may be usefull to have an optional prefix (nodename as prefix) to
"freeze" a path and prevent usage at another location. (This feature would
come along with the renaming problem but would at least not be the default
behaviour and require the awareness of the developer of the constraint he
produces).

Dominik
Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Tobias Bocanegra
>  >
>  > Well, on the other hand, it has been pointed out that the real issue is
>  > just the fact that all scripts are named "htlm.*". I'm really not very
>  > optimistic that the simple looking solution to duplicate the node name (or
>  > whatever makes up the last node in the hierarchy) to get the file name is a
>  > clear and simple concept. Telling people that they can write "foo.jsp" to
>  > get html while they have to use "pdf.jsp" to get a pdf, seems very
>  > complicated to explain and understand. And as I pointed out, as soon as you
>  > are heavily using any other format than html, you end up with the same mess
>  > (all files named pdf.*)
>  >
>
>
> I did think a bit about the refactoring and renaming problems that might
>  occur when using prefixes. Since this is a restless architecture it might be
>  necessary to replicate at least the script which is calling the script which
>  is needed by both resources. This is pretty easy when having the scripts
>  named the same way (no prefixes). Having a prefix would require renaming, as
>  well as renaming the parent node would require changing the prefix. (which
>  would break the default refactoring features for renaming in Eclipse)
>
>  Propably it is usefull to remember that a script is never identified simply
>  by its name but additionaly the path. So the name does never identify the
>  script (which script is called?) but identfies under which circumstances it
>  is called(when is it called?).
>
>  It may be usefull to have an optional prefix (nodename as prefix) to
>  "freeze" a path and prevent usage at another location. (This feature would
>  come along with the renaming problem but would at least not be the default
>  behaviour and require the awareness of the developer of the constraint he
>  produces).
i don't see you use case. usually the script is never referenced
directly but addressed via the sling resource type. if you change a
resource type, you would need to adjust the path (and of course the
script prefix) but not change it anywhere else.
i did quite some development with scripts by now for our cms-showcase,
and i think i only included a script directly in 1 or 2 special
locations. all other "includes" work via content include using the
resource type.

another idea...how about adding an optional name between the type and
the extension? eg:

/apps/myapp/foo/html.foo.jsp

the resolution will only check for the "/apps/myapp/foo/html" part,
the extension (jsp) selects the script engine and the intermediate
"foo" is cosmetics for the editors. so when renaming a resource type,
you only need to change the path in the first place. the resolution
will still work. the intermediate name can be changed later. this also
would allow for nice names like "foo/html.FooMain.jsp" or something.

WDYT?

--
toby


>
>
>  Dominik
>

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

David Nuescheler-3
hi guys,

i agree with carsten that we probably can't reach on consensus on
this list and "design" by committee in this case certainly shows its
weaknesses. this is a topic where everybody can have an opinion
about but only very few of us larger scale experience with
using the sling script resolution to solve their real-life needs.

i think that it is probably the easiest if toby and i come up with a proposal
as an actual patch that suits our needs and experiences from a users
perspective and meets the performance requirements, and then take
this a basis for discussion, and check with you guys where we have
shortfalls on the performance side of things...

generally, i would like to keep this proposal backwards compatible to
the current one, since there are only 2 or 3 that are broken and the
rest is perfectly fine and suits the needs. keeping things backwards
compatible also makes this a minor change and convenience improvement
for current users.

regards,
david


On Sat, Apr 26, 2008 at 11:14 PM, Tobias Bocanegra
<[hidden email]> wrote:

>
> >  >
>  >  > Well, on the other hand, it has been pointed out that the real issue is
>  >  > just the fact that all scripts are named "htlm.*". I'm really not very
>  >  > optimistic that the simple looking solution to duplicate the node name (or
>  >  > whatever makes up the last node in the hierarchy) to get the file name is a
>  >  > clear and simple concept. Telling people that they can write "foo.jsp" to
>  >  > get html while they have to use "pdf.jsp" to get a pdf, seems very
>  >  > complicated to explain and understand. And as I pointed out, as soon as you
>  >  > are heavily using any other format than html, you end up with the same mess
>  >  > (all files named pdf.*)
>  >  >
>  >
>  >
>  > I did think a bit about the refactoring and renaming problems that might
>  >  occur when using prefixes. Since this is a restless architecture it might be
>  >  necessary to replicate at least the script which is calling the script which
>  >  is needed by both resources. This is pretty easy when having the scripts
>  >  named the same way (no prefixes). Having a prefix would require renaming, as
>  >  well as renaming the parent node would require changing the prefix. (which
>  >  would break the default refactoring features for renaming in Eclipse)
>  >
>  >  Propably it is usefull to remember that a script is never identified simply
>  >  by its name but additionaly the path. So the name does never identify the
>  >  script (which script is called?) but identfies under which circumstances it
>  >  is called(when is it called?).
>  >
>  >  It may be usefull to have an optional prefix (nodename as prefix) to
>  >  "freeze" a path and prevent usage at another location. (This feature would
>  >  come along with the renaming problem but would at least not be the default
>  >  behaviour and require the awareness of the developer of the constraint he
>  >  produces).
>  i don't see you use case. usually the script is never referenced
>  directly but addressed via the sling resource type. if you change a
>  resource type, you would need to adjust the path (and of course the
>  script prefix) but not change it anywhere else.
>  i did quite some development with scripts by now for our cms-showcase,
>  and i think i only included a script directly in 1 or 2 special
>  locations. all other "includes" work via content include using the
>  resource type.
>
>  another idea...how about adding an optional name between the type and
>  the extension? eg:
>
>  /apps/myapp/foo/html.foo.jsp
>
>  the resolution will only check for the "/apps/myapp/foo/html" part,
>  the extension (jsp) selects the script engine and the intermediate
>  "foo" is cosmetics for the editors. so when renaming a resource type,
>  you only need to change the path in the first place. the resolution
>  will still work. the intermediate name can be changed later. this also
>  would allow for nice names like "foo/html.FooMain.jsp" or something.
>
>  WDYT?
>
>  --
>  toby
>
>
>  >
>  >
>  >  Dominik
>  >
>



--
Visit: http://dev.day.com/ - Day JCR Cup 08 - Win a MacBook Pro

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Bertrand Delacretaz
Hi,

On Sun, Apr 27, 2008 at 1:37 PM, David Nuescheler <[hidden email]> wrote:
> ... i think that it is probably the easiest if toby and i come up with a proposal
>  as an actual patch that suits our needs and experiences from a users
>  perspective and meets the performance requirements, and then take
>  this a basis for discussion...

Agreed.

> ... generally, i would like to keep this proposal backwards compatible to
>  the current one, since there are only 2 or 3 that are broken and the
>  rest is perfectly fine and suits the needs. keeping things backwards
>  compatible also makes this a minor change and convenience improvement
>  for current users....

Ok, I think we all agree the current way is not too bad, so if you can
come up with a proposal that improves it without going overboard
that's probably fine.

I'm not too worried about performance, once again this stuff can
easily be cached, and if we need to recursively walk down under a path
like /apps/foo to find all potential scripts, that's usually only a
handful of files.

-Bertrand

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Felix Meschberger-2
Hi,

Give me 5 minutes, I am just now preparing a new summary of findings we
had on a discussion this morning ;-)

Regards
Felix

Am Montag, den 28.04.2008, 15:22 +0200 schrieb Bertrand Delacretaz:

> Hi,
>
> On Sun, Apr 27, 2008 at 1:37 PM, David Nuescheler <[hidden email]> wrote:
> > ... i think that it is probably the easiest if toby and i come up with a proposal
> >  as an actual patch that suits our needs and experiences from a users
> >  perspective and meets the performance requirements, and then take
> >  this a basis for discussion...
>
> Agreed.
>
> > ... generally, i would like to keep this proposal backwards compatible to
> >  the current one, since there are only 2 or 3 that are broken and the
> >  rest is perfectly fine and suits the needs. keeping things backwards
> >  compatible also makes this a minor change and convenience improvement
> >  for current users....
>
> Ok, I think we all agree the current way is not too bad, so if you can
> come up with a proposal that improves it without going overboard
> that's probably fine.
>
> I'm not too worried about performance, once again this stuff can
> easily be cached, and if we need to recursively walk down under a path
> like /apps/foo to find all potential scripts, that's usually only a
> handful of files.
>
> -Bertrand


Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Felix Meschberger-2
In reply to this post by David Nuescheler-3
Hi all,

After re-reading this proposal and discussing it with David, also
considering any consequences with respect to backwards compatibility,
performance and usability, I would like to summarize, what we came up
with.


(0) Fundamental: Scripts and Servlets are equal

In the following discussion, I will write about scripts. This will
always include servlets as well. In fact, internally, Sling only handles
with Servlets, whereas scripts are packed inside a Servlet wrapping and
representing the script.


(I) Base: Resource Type Inheritance

While not exactly part of our discussion, resource type inheritance as
implemented for SLING-278 plays a vital role in script resolution.

Each resource type may have a resource super type, which may be defined
in various ways. One example is having a sling:resourceSuperType
property in the node addressed by the resource type. See [1] and [2] for
more details.

If a resource type has no explicit resource super type, the resource
super type is assumed to be "sling/servlet/default". That is the
resource type used for default script selection is also acting as a
basic resource type much like java.lang.Object does for other types in
the Java language.


(II) Script Locations

Scripts are looked up in a series of locations defined by the
ResourceResolver.getSearchPath() and the resource type (and resource
super types) of the requested resource:

    {scriptPathPrefix}/{resourceTypePath}

The pseudo code for iterating the locations would be something like:

        var type = resource.getResourceType();
        while (type != null) {
            for (String root: resourceResolver.getSearchPath()) {
                String path = root + type.toPath();
                findScriptsIn(path);
            }
       
            if (type == defaultServlet) {
                type = null;
            } else {
                type = getResourceSuperType(type);
                if (type == null) {
                    type = defaultServlet;
                }
            }
        }


(III) All requests are NOT equal

GET and HEAD request methods are treated differently than the other
request methods. Only for GET and HEAD requests will the request
selectors and extension be considered for script selection. For other
requests the servlet or script name (without the script extension) must
exactly match the request method.

That is for a PUT request, the script must be PUT.esp or PUT.jsp. For a
GET request with a request extension of html, the script name may be
html.esp or GET.esp.


(IV) Scripts for GET requests

Apart for supporting scripts named after the request method, scripts
handling GET and HEAD requests may be named differently for Sling to
support a more elaborate processing order.

Depending on whether request selectors are considered, a script may have
two forms:

  a. Ignoring request selectors (e.g. there are none in the request URI)
     {resourceTypeLabel}.{requestExtension}.{scriptExtension}

  b. Handling request selectors
     {selectorStringPath}.{requestExtension}.{scriptExtension}


The constituents of these script names are as follows:

   {resourceTypeLabel} - The last path segment of the path created from
the
               resource type. This part is optional if the
{requestExtension}
               is used in the script name.
   {requestExtension} - The request extension. This part may be ommitted
if
               the request extension is "html", otherwise this part is
required.
               If this part is ommitted, the {resourceTypeLabel} is
required
               in the case of ignoring the selectors.
    {scriptExtension} - The extension, e.g. "esp" or "jsp", identifying
the
               scripting langauage used.
    {selectorStringPath} - The selector string converted to a path,
along the
               lines of selectorString.replace('.', '/').


(V) Priority

The rules for script path priorization is defined as follows:

   * The more request selectors are matched, the better
   * A script including the request extension matches better
     than one without a request extension (for html only)
   * A script found earlier matches better than a script
     found later in the processing order. This means, that
     script closer to the original resource type in the
     resource type hierarchy is considered earlier.


(VI) Examples

Taking up again the list of potential script paths for a request of a
resource whose resource type is sling:sample and the request selectors
are "print.a4" and the request extension is "html" could be:

   (0) GET.esp
   (1) sample.esp
   (2) html.esp
   (3) print.esp
   (4) print/a4.esp
   (5) print.html.esp
   (6) print/a4.html.esp

The priority of script selection would (6) - (4) - (5) - (3) - (2) - (1)
- (0). Note that (4) is a better match than (5) because it matches more
selectors even though (5) has an extension match where (4) does not.


WDYT ?

Regards
Felix

[1]
http://www.mail-archive.com/sling-dev@.../msg02365.html
[2] http://issues.apache.org/jira/browse/SLING-278


Am Freitag, den 25.04.2008, 16:40 +0200 schrieb David Nuescheler:

> hi guys,
>
> after going through this entire discussion and looking at issue:
> https://issues.apache.org/jira/browse/SLING-387
> i would like to raise the following point.
>
> i think it is important that this change was originally suggested to
> make the simple cases as simple and intuitive as possible for
> the user of sling and not to come up with something that is really
> easy and consistent to map for the sling implementation.
>
> let me try to explain with an example:
> as a user of sling i would like to have my app in
> /apps/myapp and lets say i have a node of resourceType
> "myapp/homepage" at "/content/myapp".
>
> i would like to to be able to structure my applications as follows:
>
> (1) /apps/myapp/homepage/hompage.esp (or html.esp or GET.esp)
> (2) /apps/myapp/homepage/edit.esp (or edit.html.esp)
> (3) /apps/myapp/homepage/header/highlight.jpg.esp
> (4) /apps/myapp/homepage/header/selected.jpg.esp
> (5) /apps/myapp/homepage/header/small.jpg.esp
>
> where
>
> /content/myapp.html -> (1)
> /content/myapp.edit.html -> (2)
> /content/myapp.header.highlight.jpg -> (3)
> /content/myapp.header.selected.jpg -> (4)
> /content/myapp.header.small.jpg -> (5)
>
> i think it is important that we avoid unnecessary repetition at any point
> and we would allow for enough flexibility in the /apps directory allow
> the user to come up with something short, distinct and meaningful.
>
> regards,
> david
>
>
>
>
>
> On Fri, Apr 18, 2008 at 6:34 PM, Tobias Bocanegra
> <[hidden email]> wrote:
> > hi,
> >  i just want to add, that most of the requests that actually hit sling
> >  will probably be plain .html requests with no selectors. so the
> >  /apps/foo/foo.jsp will probably resolve those requests. since requests
> >  that usually need selectors are image requests which are very good
> >  cacheable in a higher teer. so i don't think that in a real-live
> >  scenario, the resource resolution performance is that relevant. and of
> >  course it can easily be cached.
> >
> >  --
> >  toby
> >
> >
> >
> >
> >  On 4/18/08, Carsten Ziegeler <[hidden email]> wrote:
> >  > Felix Meschberger wote:
> >  >
> >  >
> >  > > Hi,
> >  > >
> >  > > Am Freitag, den 18.04.2008, 16:35 +0200 schrieb Carsten Ziegeler:
> >  > >
> >  > > > Having scripts in /apps and /libs where /libs has precendence of /apps
> >  > still feels not very intuitive for me.
> >  > > >
> >  > >
> >  > > It is the other way around: /apps has precedence over /libs. And this is
> >  > > IMHO intuitive.
> >  > >
> >  > >
> >  >  Hehe, you see, it's not intuitive for me (ok, I'll write down 100 times
> >  > "apps has precedence over libs, apps has precedence over libs..."
> >  >
> >  >
> >  >  Carsten
> >  >
> >  >  --
> >  >  Carsten Ziegeler
> >  >  [hidden email]
> >  >
> >
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Bertrand Delacretaz
Hi,

On Mon, Apr 28, 2008 at 5:33 PM, Felix Meschberger <[hidden email]> wrote:
>  ...After re-reading this proposal and discussing it with David, also
>  considering any consequences with respect to backwards compatibility,
>  performance and usability, I would like to summarize, what we came up
>  with....

Thanks, your proposal looks good to me!

-Bertrand

123