Simplifying script paths and names?

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

Simplifying script paths and names?

Bertrand Delacretaz
Hi,

Currently, working with selectors requires you to put scripts in
subfolders, for example

/apps/foo/html.esp
/apps/foo/someselector/html.esp

and worse, all GET scripts which produce html are named html.esp,
which can be confusing when editing them.

We talked about this with David and Felix, here's a proposal for
simplifying those names in the "happy case", while keeping the current
conventions to resolve potential name conflicts where needed. Comments
welcome.


= Proposal =

The following variants should be accepted for script names, examples:

a) sling:resourceType=foo, request = bar.html

Sling searches for the following scripts and uses the first one found:

  /apps/foo/html.esp
  /apps/foo/foo.esp

The only change is that the script used for html rendering can
optionally be named foo.esp, to avoid having many scripts called
"html.esp" which is not practical when opening many of them in an
editor or IDE.

a) sling:resourceType=foo, request = bar.selector.html

The following scripts can be used to process this request, the first
one found being used:

/apps/foo/selector/html.esp
/apps/foo/selector.html.esp (same but with dots instead a subfolder)
/apps/foo/selector.esp
/apps/foo/html.esp (not specific to the selector)
/apps/foo/foo.esp (not specific either)

In the "happy case" people would then just have those two scripts to
handle the above cases:

/apps/foo/foo.esp
/apps/foo/selector.esp

-Bertrand

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Carsten Ziegeler
Bertrand Delacretaz wrote:

> Hi,
>
> Currently, working with selectors requires you to put scripts in
> subfolders, for example
>
> /apps/foo/html.esp
> /apps/foo/someselector/html.esp
>
> and worse, all GET scripts which produce html are named html.esp,
> which can be confusing when editing them.
>
I totally agree.

> We talked about this with David and Felix, here's a proposal for
> simplifying those names in the "happy case", while keeping the current
> conventions to resolve potential name conflicts where needed. Comments
> welcome.
>
>
> = Proposal =
>
> The following variants should be accepted for script names, examples:
>
> a) sling:resourceType=foo, request = bar.html
>
> Sling searches for the following scripts and uses the first one found:
>
>   /apps/foo/html.esp
>   /apps/foo/foo.esp
>
> The only change is that the script used for html rendering can
> optionally be named foo.esp, to avoid having many scripts called
> "html.esp" which is not practical when opening many of them in an
> editor or IDE.
>
> a) sling:resourceType=foo, request = bar.selector.html
>
> The following scripts can be used to process this request, the first
> one found being used:
>
> /apps/foo/selector/html.esp
> /apps/foo/selector.html.esp (same but with dots instead a subfolder)
> /apps/foo/selector.esp
> /apps/foo/html.esp (not specific to the selector)
> /apps/foo/foo.esp (not specific either)
>
> In the "happy case" people would then just have those two scripts to
> handle the above cases:
>
> /apps/foo/foo.esp
> /apps/foo/selector.esp
>
Hmm, isn't there a better way? This solves the problem only partially -
I ran
into the same trouble if I want to support a different format like pdf;
still all my scripts would be named "pdf.esp".

Without further thinking if this creates other problems, would about
using a simple rule like "replacing the last slash with a dot"?

So instead of looking it /apps/foo/html.esp Sling would look at
/apps/foo.html.esp.

With selectors this becomes /apps/foo.selector.html.esp".

Carsten

--
Carsten Ziegeler
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Alexander Klimetschek

Am 14.04.2008 um 18:11 schrieb Carsten Ziegeler:

> Hmm, isn't there a better way? This solves the problem only  
> partially - I ran
> into the same trouble if I want to support a different format like  
> pdf; still all my scripts would be named "pdf.esp".
>
> Without further thinking if this creates other problems, would about  
> using a simple rule like "replacing the last slash with a dot"?
>
> So instead of looking it /apps/foo/html.esp Sling would look at /
> apps/foo.html.esp.
>
> With selectors this becomes /apps/foo.selector.html.esp".

Hmm, wouldn't it be solved by extending the proposed list as follows?  
Here each selector-specific script can also be named with the  
(uniquely named) resource type in the file name:

/apps/foo/selector/html.esp
/apps/foo/selector.html.esp (same but with dots instead a subfolder)
/apps/foo/foo.selector.html.esp (NEW, for unique filenames of selector  
scripts)
/apps/foo/selector.esp
/apps/foo/foo.selector.esp (NEW, for unique filenames of selector  
scripts)
/apps/foo/html.esp (not specific to the selector)
/apps/foo/foo.esp (not specific either)


Alex

--
Alexander Klimetschek
[hidden email]

 >> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<





Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Carsten Ziegeler
Ok, *if* we want to change the behaviour of the script resolution, we
should definitly do this before our first planned release.

Carsten

Alexander Klimetschek wrote:

>
> Am 14.04.2008 um 18:11 schrieb Carsten Ziegeler:
>> Hmm, isn't there a better way? This solves the problem only partially
>> - I ran
>> into the same trouble if I want to support a different format like
>> pdf; still all my scripts would be named "pdf.esp".
>>
>> Without further thinking if this creates other problems, would about
>> using a simple rule like "replacing the last slash with a dot"?
>>
>> So instead of looking it /apps/foo/html.esp Sling would look at
>> /apps/foo.html.esp.
>>
>> With selectors this becomes /apps/foo.selector.html.esp".
>
> Hmm, wouldn't it be solved by extending the proposed list as follows?
> Here each selector-specific script can also be named with the (uniquely
> named) resource type in the file name:
>
> /apps/foo/selector/html.esp
> /apps/foo/selector.html.esp (same but with dots instead a subfolder)
> /apps/foo/foo.selector.html.esp (NEW, for unique filenames of selector
> scripts)
> /apps/foo/selector.esp
> /apps/foo/foo.selector.esp (NEW, for unique filenames of selector scripts)
> /apps/foo/html.esp (not specific to the selector)
> /apps/foo/foo.esp (not specific either)
>
>
> Alex
>
> --
> Alexander Klimetschek
> [hidden email]
>
>  >> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<
>
>
>
>
>


--
Carsten Ziegeler
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Bertrand Delacretaz
In reply to this post by Alexander Klimetschek
Hi,

On Mon, Apr 14, 2008 at 6:26 PM, Alexander Klimetschek <[hidden email]> wrote:

>
> ... /apps/foo/selector/html.esp
>  /apps/foo/selector.html.esp (same but with dots instead a subfolder)
>  /apps/foo/foo.selector.html.esp (NEW, for unique filenames of selector
> scripts)
>  /apps/foo/selector.esp
>  /apps/foo/foo.selector.esp (NEW, for unique filenames of selector scripts)
>
>  /apps/foo/html.esp (not specific to the selector)
>  /apps/foo/foo.esp (not specific either)...

I like this, and IIUC the "what to use for pdf" problem mentioned by
Carsten is also solved, using /apps/foo/selector.pdf.esp for example?

I don't like removing the slash after foo, for example
"/apps/foo.selector.html.esp", because that means that some foo
scripts are outside of the foo folder. Having them all under
/apps/foo/ makes it much easier to copy and move complete
"applications".

I'm not sure if I'd be able to implement this before our first
release, that depends on other priorities in my current project.

-Bertrand

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Carsten Ziegeler
Bertrand Delacretaz wrote:

> Hi,
>
> On Mon, Apr 14, 2008 at 6:26 PM, Alexander Klimetschek <[hidden email]> wrote:
>> ... /apps/foo/selector/html.esp
>>  /apps/foo/selector.html.esp (same but with dots instead a subfolder)
>>  /apps/foo/foo.selector.html.esp (NEW, for unique filenames of selector
>> scripts)
>>  /apps/foo/selector.esp
>>  /apps/foo/foo.selector.esp (NEW, for unique filenames of selector scripts)
>>
>>  /apps/foo/html.esp (not specific to the selector)
>>  /apps/foo/foo.esp (not specific either)...
>
> I like this, and IIUC the "what to use for pdf" problem mentioned by
> Carsten is also solved, using /apps/foo/selector.pdf.esp for example?
>
> I don't like removing the slash after foo, for example
> "/apps/foo.selector.html.esp", because that means that some foo
> scripts are outside of the foo folder. Having them all under
> /apps/foo/ makes it much easier to copy and move complete
> "applications".
So, you would duplicate the last path element instead? (like
.../foo/foo.esp instead of .../foo.esp)
>
> I'm not sure if I'd be able to implement this before our first
> release, that depends on other priorities in my current project.
>
I would love to see a complete description (followed by a
discussion/vote) before changing/implementing something.

Carsten

--
Carsten Ziegeler
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Felix Meschberger-2
Hi all,

Basically, I agree with the proposed extensions. But we should try to
not exagerate ... After all we have to concoct this all (1) in a decent
description and (2) into code.

So to continue my discussion, lets add another example:

  resource type = sling:sample
  uri = /foo/bar.print.a4.html

thus

   resource type path = sling/sample
   selector string = print.a4
   extension = html

First lets reconsider how a script is looked up today (assume a search
path of [ /apps, /libs ] :

 (1) check for resource type
   /apps/sling/sample/print/a4/html.*
   /apps/sling/sample/print/html.*
   /apps/sling/sample/html.*
   /libs/sling/sample/print/a4/html.*
   /libs/sling/sample/print/html.*
   /libs/sling/sample/html.*
   /apps/sling/sample/print/a4/GET.*
   /apps/sling/sample/print/GET.*
   /apps/sling/sample/GET.*
   /libs/sling/sample/print/a4/GET.*
   /libs/sling/sample/print/GET.*
   /libs/sling/sample/GET.*
 (2) check for resource super type
   { repeat above steps for resource super types }
 (3) check for default servlet
   /apps/sling/servlet/default/print/a4/html.*
   /apps/sling/servlet/default/print/html.*
   /apps/sling/servlet/default/html.*
   /libs/sling/servlet/default/print/a4/html.*
   /libs/sling/servlet/default/print/html.*
   /libs/sling/servlet/default/html.*
   /apps/sling/servlet/default/print/a4/GET.*
   /apps/sling/servlet/default/print/GET.*
   /apps/sling/servlet/default/GET.*
   /libs/sling/servlet/default/print/a4/GET.*
   /libs/sling/servlet/default/print/GET.*
   /libs/sling/servlet/default/GET.*
   
This is - ignoreing resource super types - at most 24 checks ! Agreed,
this is worst case but falling back to the default GET servlet really
requires this number and I think, this is not really worst case, but
realistic.

Now lets add support for scripts named after the last part of the
resource type, e.g. "sample" here: For each check for html.* we add
another check for that name :
   
 (1) check for resource type
   /apps/sling/sample/print/a4/html.*
   /apps/sling/sample/print/html.*
   /apps/sling/sample/html.*
   /apps/sling/sample/sample.html.*
   /apps/sling/sample/sample.*
   /libs/sling/sample/print/a4/html.*
   /libs/sling/sample/print/html.*
   /libs/sling/sample/html.*
   /libs/sling/sample/sample.html.*
   /libs/sling/sample/sample.*
   /apps/sling/sample/print/a4/GET.*
   /apps/sling/sample/print/GET.*
   /apps/sling/sample/GET.*
   /libs/sling/sample/print/a4/GET.*
   /libs/sling/sample/print/GET.*
   /libs/sling/sample/GET.*
 (2) check for resource super type
   { repeat above steps for resource super types }
 (3) check for default servlet
   /apps/sling/servlet/default/print/a4/html.*
   /apps/sling/servlet/default/print/html.*
   /apps/sling/servlet/default/html.*
   /apps/sling/servlet/default/sample.html.*
   /apps/sling/servlet/default/sample.*
   /libs/sling/servlet/default/print/a4/html.*
   /libs/sling/servlet/default/print/html.*
   /libs/sling/servlet/default/html.*
   /libs/sling/servlet/default/sample.html.*
   /libs/sling/servlet/default/sample.*
   /apps/sling/servlet/default/print/a4/GET.*
   /apps/sling/servlet/default/print/GET.*
   /apps/sling/servlet/default/GET.*
   /libs/sling/servlet/default/print/a4/GET.*
   /libs/sling/servlet/default/print/GET.*
   /libs/sling/servlet/default/GET.*

This is just beginning and we generate a whole lot of combinations (task
for the student: How many, actually ? ) and we not even started using
the selector as dot-separated instead of a relative path (slash
separated).

Don't get me wrong: I am all for simplifying matters. But for now we are
merely adding more options.... And this is not simplifying at all.

So here is my proposal: We don't search a subtree below the resource
type path anymore but expect the scripts to all be in the same folder.
That is the selector string is used as is as a file name part. To find a
script we apply a longest substring match. The generic script name would
then be:

     {pathPrefix}/{resourceTypePath}/{resourceTypeLabel}.{selectorString}.{extension}.*

where:
   {pathPrefix}        - search path prefix, e.g. /apps
   {resourceTypePath}  - resource type converted to path, e.g.
sling/sample
   {resourceTypeLabel} - last part of resource type converted, e.g.
sample
   {selectorString}    - the selector string, e.g. print.a4
   {extension}         - the request extension, e.g. html, but may also
be GET
   *                   - any script extension

The implementation is probably very easy: We just find a script whose
name has the most specific match in terms of selectorString and
extension. Because all scripts are looked up in the same parent node, we
can just get a single listing and look for the best match. (working on
subtrees we have to access pretty exhaustive with multiple listings etc.

This is, of course, not compatible with what we do currently (with
respect to selectors). But I am convinced, that we have to make a
concession on one end to get the other end. We cannot easily get all.

WDYT ?

Regards
Felix


Am Mittwoch, den 16.04.2008, 14:52 +0200 schrieb Carsten Ziegeler:

> Bertrand Delacretaz wrote:
> > Hi,
> >
> > On Mon, Apr 14, 2008 at 6:26 PM, Alexander Klimetschek <[hidden email]> wrote:
> >> ... /apps/foo/selector/html.esp
> >>  /apps/foo/selector.html.esp (same but with dots instead a subfolder)
> >>  /apps/foo/foo.selector.html.esp (NEW, for unique filenames of selector
> >> scripts)
> >>  /apps/foo/selector.esp
> >>  /apps/foo/foo.selector.esp (NEW, for unique filenames of selector scripts)
> >>
> >>  /apps/foo/html.esp (not specific to the selector)
> >>  /apps/foo/foo.esp (not specific either)...
> >
> > I like this, and IIUC the "what to use for pdf" problem mentioned by
> > Carsten is also solved, using /apps/foo/selector.pdf.esp for example?
> >
> > I don't like removing the slash after foo, for example
> > "/apps/foo.selector.html.esp", because that means that some foo
> > scripts are outside of the foo folder. Having them all under
> > /apps/foo/ makes it much easier to copy and move complete
> > "applications".
> So, you would duplicate the last path element instead? (like
> .../foo/foo.esp instead of .../foo.esp)
> >
> > I'm not sure if I'd be able to implement this before our first
> > release, that depends on other priorities in my current project.
> >
> I would love to see a complete description (followed by a
> discussion/vote) before changing/implementing something.
>
> Carsten
>


Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Carsten Ziegeler
Felix Meschberger wrote:
> This is just beginning and we generate a whole lot of combinations (task
> for the student: How many, actually ? ) and we not even started using
> the selector as dot-separated instead of a relative path (slash
> separated).
>
> Don't get me wrong: I am all for simplifying matters. But for now we are
> merely adding more options.... And this is not simplifying at all.
Yes, that were exactly my fears with the proposal as well. And that's
why I suggested to change the current solution by using file names
instead of paths :)

>
> So here is my proposal: We don't search a subtree below the resource
> type path anymore but expect the scripts to all be in the same folder.
> That is the selector string is used as is as a file name part. To find a
> script we apply a longest substring match. The generic script name would
> then be:
>
>      {pathPrefix}/{resourceTypePath}/{resourceTypeLabel}.{selectorString}.{extension}.*
>
> where:
>    {pathPrefix}        - search path prefix, e.g. /apps
>    {resourceTypePath}  - resource type converted to path, e.g.
> sling/sample
>    {resourceTypeLabel} - last part of resource type converted, e.g.
> sample
>    {selectorString}    - the selector string, e.g. print.a4
>    {extension}         - the request extension, e.g. html, but may also
> be GET
>    *                   - any script extension
>
> The implementation is probably very easy: We just find a script whose
> name has the most specific match in terms of selectorString and
> extension. Because all scripts are looked up in the same parent node, we
> can just get a single listing and look for the best match. (working on
> subtrees we have to access pretty exhaustive with multiple listings etc.
Yes, this looks good to me and makes everything simpler.

>
> This is, of course, not compatible with what we do currently (with
> respect to selectors). But I am convinced, that we have to make a
> concession on one end to get the other end. We cannot easily get all.
Exactly, that's why I wanted to discuss this before a release :)

Carsten
--
Carsten Ziegeler
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Carsten Ziegeler
Rethinking the whole issue, I'm not sure if it's really worth changing
the behaviour as this would mean that all users have to change their
paths for scripts.

So which real problems are we trying to fix?

Carsten
--
Carsten Ziegeler
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Bertrand Delacretaz
On Thu, Apr 17, 2008 at 8:20 AM, Carsten Ziegeler <[hidden email]> wrote:
> ...Rethinking the whole issue, I'm not sure if it's really worth changing the
> behaviour as this would mean that all users have to change their paths for
> scripts....

You mean our two users? Just kidding, but I'm not sure if we have that
many users at the moment.

> ... So which real problems are we trying to fix?...

1) Most scripts, being GET scripts for html content in a typical app,
are named html.esp (or html.whatever depending on the language). That
can be confusing when editing them, and lead to errors, developer
usability suffers.

2) Having all scripts that relate to a given resource type in the same
folder, as opposed to split into several folders as is currently the
case, makes it easier to have an overview of what's going on.

I agree that it's late to make such a change, but the benefits seem
worth the effort for me, and now (i.e. before we add more examples and
documentation) seems to be the right time.

-Bertrand

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

gertv
L.S.,

As a user, I wouldn't mind having to change the paths of my scripts now
if this improves developer usability by avoiding the
15-tabs-called-html.esp-in-gedit ;)

Gert

Bertrand Delacretaz wrote:
> On Thu, Apr 17, 2008 at 8:20 AM, Carsten Ziegeler <[hidden email]> wrote:
>> ...Rethinking the whole issue, I'm not sure if it's really worth changing the
>> behaviour as this would mean that all users have to change their paths for
>> scripts....
>
> You mean our two users? Just kidding, but I'm not sure if we have that
> many users at the moment.
>

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Juanjo Vázquez
In reply to this post by Bertrand Delacretaz
Hi,

Absolute agree, I think now would be the moment to implements this change.

Regards,

Juanjo

On Thu, Apr 17, 2008 at 9:00 AM, Bertrand Delacretaz <[hidden email]>
wrote:

> On Thu, Apr 17, 2008 at 8:20 AM, Carsten Ziegeler <[hidden email]>
> wrote:
> > ...Rethinking the whole issue, I'm not sure if it's really worth
> changing the
> > behaviour as this would mean that all users have to change their paths
> for
> > scripts....
>
> You mean our two users? Just kidding, but I'm not sure if we have that
> many users at the moment.
>
> > ... So which real problems are we trying to fix?...
>
> 1) Most scripts, being GET scripts for html content in a typical app,
> are named html.esp (or html.whatever depending on the language). That
> can be confusing when editing them, and lead to errors, developer
> usability suffers.
>
> 2) Having all scripts that relate to a given resource type in the same
> folder, as opposed to split into several folders as is currently the
> case, makes it easier to have an overview of what's going on.
>
> I agree that it's late to make such a change, but the benefits seem
> worth the effort for me, and now (i.e. before we add more examples and
> documentation) seems to be the right time.
>
> -Bertrand
>
Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Alexander Klimetschek
In reply to this post by Bertrand Delacretaz
> 1) Most scripts, being GET scripts for html content in a typical app,
> are named html.esp (or html.whatever depending on the language). That
> can be confusing when editing them, and lead to errors, developer
> usability suffers.

+1

I have not much experience with Sling and html.esp in particular, but  
I know this problem from Cocoon's sitemap.xmap across various modules  
(later renamed them, which was luckily possible, but you don't think  
about that in the beginning...).

And sometimes the tools make it even more difficult: Eclipse <= 3.2 on  
Mac for example, displaying only standard "sitemap.xmap" in the tabs,  
had *no way* of determing the full name of the currently viewed file -  
not in the application title, not via a tooltip, nowhere - you could  
only press sync in the typically huge package explorer tree, which is  
the exact opposite of fast switching between files...

The "it's too late" argument should be turned around: "if you won't do  
it now, you'll never do it!"

Alex

--
Alexander Klimetschek
[hidden email]

 >> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<





Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Michael Marth
+1

having 10 "html.esp" tabs open is quite a pain


On Thu, Apr 17, 2008 at 10:48 AM, Alexander Klimetschek
<[hidden email]> wrote:

>
> > 1) Most scripts, being GET scripts for html content in a typical app,
> > are named html.esp (or html.whatever depending on the language). That
> > can be confusing when editing them, and lead to errors, developer
> > usability suffers.
> >
>
>  +1
>
>  I have not much experience with Sling and html.esp in particular, but I
> know this problem from Cocoon's sitemap.xmap across various modules (later
> renamed them, which was luckily possible, but you don't think about that in
> the beginning...).
>
>  And sometimes the tools make it even more difficult: Eclipse <= 3.2 on Mac
> for example, displaying only standard "sitemap.xmap" in the tabs, had *no
> way* of determing the full name of the currently viewed file - not in the
> application title, not via a tooltip, nowhere - you could only press sync in
> the typically huge package explorer tree, which is the exact opposite of
> fast switching between files...
>
>  The "it's too late" argument should be turned around: "if you won't do it
> now, you'll never do it!"
>
>
>
>  Alex
>
>  --
>  Alexander Klimetschek
>  [hidden email]
>
>  >> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<
>
>
>
>
>



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

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Bertrand Delacretaz
In reply to this post by Felix Meschberger-2
On Wed, Apr 16, 2008 at 5:11 PM, Felix Meschberger <[hidden email]> wrote:

>  ...The generic script name would
>  then be:
>
>      {pathPrefix}/{resourceTypePath}/{resourceTypeLabel}.{selectorString}.{extension}.*
> ...

I like the idea but I'd express it slightly differently:

{scriptPathPrefix}/{resourceTypePath}/{resourceTypeLabel}.{selectorString}.{requestMethod}.{requestExtension}.{scriptExtension}.

And, to cover the most common cases, define that

1) If {requestMethod}.{requestExtension}.== "GET.html", use and empty
string instead (in all cases - not optional):

To have scripts named

/app/foo/bar/bar.esp

instead of

/app/foo/bar/bar.GET.html.esp

for the common GET.html case.

2) If {requestMethod} is not GET or HEAD, {requestExtension} can
optionally be dropped from the script name

To have scripts named

/app/foo/bar/bar.POST.esp

instead of

/app/foo/bar/bar.POST.html.esp

As usually a POST or other method does not care about the request
extension, except maybe to select a different rendering of the result,
in which case POST.html.esp or POST.xml.esp can still be used.

3) {selectorString} is not necessarily the whole string of selectors,
Sling does a longest string match on this part, so that the first of
the following scripts that exists will be used for a request where
resourceType = foo/bar and selectors = "print.a4.color":

/apps/foo/bar/bar.print.a4.color.esp
/apps/foo/bar/bar.print.a4.esp
/apps/foo/bar/bar.print.esp
/apps/foo/bar/bar.esp

- o -

3) Is what we're doing already, and means that we cannot use a longest
string match on the whole thing anyway, so I think it's not much more
complicated to implement 1) and 2) as well. Those make the common
cases much nicer.

Note also that, if needed, it would be trivial to cache the result of
those decisions, by just keeping them around and invalidating the
whole cache when anything changes under /apps, based on JCR
observation. So it's not that bad if the selection algorithm is a bit
more complex. That's also something that's easy to add to our
automated tests, so it will be robust.

WDYT?

-Bertrand

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Bertrand Delacretaz
On Fri, Apr 18, 2008 at 9:21 AM, Bertrand Delacretaz
<[hidden email]> wrote:

>...  /app/foo/bar/bar.POST.esp ...

Does the upper/lowercase mix work for our Windows users (assuming we have any)?

I have this vague feeling of Windows being braindead when it comes to
mixing case in filenames, but I haven't used it for ages.

If Windows people could verify that they're able to create a file with
such a name reliably via WebDAV, that'd help.

Worst case we could drop the uppercase requirement for method names,
but I kinda like it as it expresses the difference between selecting a
script by request extension and selecting by http method name.

-Bertrand

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Felix Meschberger-2
In reply to this post by Bertrand Delacretaz
Hi all,

Am Freitag, den 18.04.2008, 09:21 +0200 schrieb Bertrand Delacretaz:

> On Wed, Apr 16, 2008 at 5:11 PM, Felix Meschberger <[hidden email]> wrote:
>
> >  ...The generic script name would
> >  then be:
> >
> >      {pathPrefix}/{resourceTypePath}/{resourceTypeLabel}.{selectorString}.{extension}.*
> > ...
>
> I like the idea but I'd express it slightly differently:
>
> {scriptPathPrefix}/{resourceTypePath}/{resourceTypeLabel}.{selectorString}.{requestMethod}.{requestExtension}.{scriptExtension}.

+1

My concern now is, how do we weight these parts:

   {scriptPathPrefix}/{resourceTypePath} - Required, scripts will
otherwise not be found
   {resourceTypeLabel} - optional, resolve doesn't care, that is no
preference
   {selectorString} - Better is longer match
   {requestMethod} - Better is to have it, required for non-GET
   {requestExtension} - Better is to have it
   {scriptExtension} - resolve only cares insofar as to find a
ScriptEngine


Now, given a GET request to bar.print.a4.html, what is the priority
order for the following (porential) script names ?

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

It would probably be (6) - (5) - (2) - (4) - (3) - (1)

If there is a catch, e.g. between print.esp and print.jsp, the first
script in the listing would be selected (of course, there should not be
a catch...)

BTW, I completely agree with Bertrand that this is not very complex to
implement as it is merely repeated string operations on a list of script
paths.

WDYT ?

Regards
Felix


Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Michael Marth
In reply to this post by Bertrand Delacretaz
>
> If Windows people could verify that they're able to create a file with
> such a name reliably via WebDAV, that'd help.



Are you talking to me? :)

I checked on Vista and XP using the native WebDAV mount as well Web Drive. I
also created files in CRX's Content Explorer and looked at them through
WebDAV. In all cases the cases were preserved.

Michael




>
>
> Worst case we could drop the uppercase requirement for method names,
> but I kinda like it as it expresses the difference between selecting a
> script by request extension and selecting by http method name.
>
> -Bertrand
>



--
Michael Marth | Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/
Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Bertrand Delacretaz
On Fri, Apr 18, 2008 at 10:33 AM, Michael Marth <[hidden email]> wrote:
> >
>  > ...If Windows people could verify that they're able to create a file with
>  > such a name reliably via WebDAV, that'd help.
>
>  Are you talking to me? :)...

Ah right - I watched your screencasts, I should have known.

> ... I checked on Vista and XP using the native WebDAV mount as well Web Drive. I
>  also created files in CRX's Content Explorer and looked at them through
>  WebDAV. In all cases the cases were preserved....

Cool. So we're fine to use POST and other uppercase method names for
our scripts, thanks for checking.

-Bertrand

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Bertrand Delacretaz
In reply to this post by Felix Meschberger-2
On Fri, Apr 18, 2008 at 9:56 AM, Felix Meschberger <[hidden email]> wrote:
>  > ...{scriptPathPrefix}/{resourceTypePath}/{resourceTypeLabel}.{selectorString}.{requestMethod}.{requestExtension}.{scriptExtension}.
>
>  +1
>
>  My concern now is, how do we weight these parts:
>
>    {scriptPathPrefix}/{resourceTypePath} - Required, scripts will
>  otherwise not be found

ok

>    {resourceTypeLabel} - optional, resolve doesn't care, that is no
>  preference

I'd make it required, to avoid having too many options. We can always
make it optional later, while the opposite would not be
backwards-compatible.

>    {selectorString} - Better is longer match

ok

>    {requestMethod} - Better is to have it, required for non-GET
>    {requestExtension} - Better is to have it

I'd use my suggested rules as the only options here:

rule A)
{requestMethod}.{requestExtension} == "GET.html" -> required to use an
empty string

rule B)
{requestMethod} != "GET" or "HEAD" -> {requestExtension} is optional

I think this reduces the set of possible combinations, and the rules
are based on safe vs. unsafe http methods, so that's not too bad.

>    {scriptExtension} - resolve only cares insofar as to find a ScriptEngine

ok

>
>  Now, given a GET request to bar.print.a4.html, what is the priority
>  order for the following (porential) script names ?
>
>    (1) .../print.esp
>    (2) .../print.a4.esp
>    (3) .../print.html.esp
>    (4) .../print.GET.html.esp
>    (5) .../print.a4.html.esp
>    (6) .../print.a4.GET.html.esp
>
>  It would probably be (6) - (5) - (2) - (4) - (3) - (1)

Yes, more specific names should always win over less-specific ones.
But with my above suggested rules, only the following names would be
allowed (in priority order):

print.a4.esp
print.esp

This is a good example of how my rule A) reduces the number of
possible combinations, that does not matter too much for the
implementation, but it's IMHO easier to explain.

-Bertrand

123