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?

Felix Meschberger-2
Hi,

Am Freitag, den 18.04.2008, 10:44 +0200 schrieb Bertrand Delacretaz:

> 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.

fine with me.

>
> >    {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

At first sight, I could agree. But thinking again about how Servlets
would be merged into the Resource Tree view with their registration
properties for virtual path building, we should allow GET and/or html.
Otherwise a servlet could not be registered for, say, GET and POST
explicitly.

We should not treat html special in that we prevent it from being used
as part of the script name. Rather we make it optional; always. It is
then the responsibility of the script programmer to cope with the
situation.

>
> 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.

Yes. It is also easy to describe: The requestExtension is optional (all
the time actually, see above) while the requestMethod is required for
non-GET (and non-HEAD) only and optional for GET/HEAD requests. This
still reflects the separation of safe vs. unsafe methods.

Regards
Felix

>
> >    {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


Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Bertrand Delacretaz
On Fri, Apr 18, 2008 at 11:11 AM, Felix Meschberger <[hidden email]> wrote:

>  Am Freitag, den 18.04.2008, 10:44 +0200 schrieb Bertrand Delacretaz:
>  >... I'd use my suggested rules as the only options here:
>  >
>  > rule A)
>  > {requestMethod}.{requestExtension} == "GET.html" -> required to use an
>  > empty string
>
>  At first sight, I could agree. But thinking again about how Servlets
>  would be merged into the Resource Tree view with their registration
>  properties for virtual path building, we should allow GET and/or html.
>  Otherwise a servlet could not be registered for, say, GET and POST
>  explicitly....

Ok, I didn't consider the servlets selection - I agree with your
suggested optional parts then, except resourceTypeLabel which is
required, as discussed.

> ... We should not treat html special in that we prevent it from being used
>  as part of the script name. Rather we make it optional; always. It is
>  then the responsibility of the script programmer to cope with the
>  situation...

Ok, if that makes the overall resolution mechanism better.

> ...It is also easy to describe: The requestExtension is optional (all
>  the time actually, see above) while the requestMethod is required for
>  non-GET (and non-HEAD) only and optional for GET/HEAD requests. This
>  still reflects the separation of safe vs. unsafe methods...

Ok.

-Bertrand

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Felix Meschberger-2
Hi,

So, I think we have some kind of a consensus and here is issue SLING-387
[1] covering this change.

Regards
Felix

[1] https://issues.apache.org/jira/browse/SLING-387

Am Freitag, den 18.04.2008, 11:16 +0200 schrieb Bertrand Delacretaz:

> On Fri, Apr 18, 2008 at 11:11 AM, Felix Meschberger <[hidden email]> wrote:
>
> >  Am Freitag, den 18.04.2008, 10:44 +0200 schrieb Bertrand Delacretaz:
> >  >... I'd use my suggested rules as the only options here:
> >  >
> >  > rule A)
> >  > {requestMethod}.{requestExtension} == "GET.html" -> required to use an
> >  > empty string
> >
> >  At first sight, I could agree. But thinking again about how Servlets
> >  would be merged into the Resource Tree view with their registration
> >  properties for virtual path building, we should allow GET and/or html.
> >  Otherwise a servlet could not be registered for, say, GET and POST
> >  explicitly....
>
> Ok, I didn't consider the servlets selection - I agree with your
> suggested optional parts then, except resourceTypeLabel which is
> required, as discussed.
>
> > ... We should not treat html special in that we prevent it from being used
> >  as part of the script name. Rather we make it optional; always. It is
> >  then the responsibility of the script programmer to cope with the
> >  situation...
>
> Ok, if that makes the overall resolution mechanism better.
>
> > ...It is also easy to describe: The requestExtension is optional (all
> >  the time actually, see above) while the requestMethod is required for
> >  non-GET (and non-HEAD) only and optional for GET/HEAD requests. This
> >  still reflects the separation of safe vs. unsafe methods...
>
> Ok.
>
> -Bertrand


Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Carsten Ziegeler
Felix Meschberger wrote:
> Hi,
>
> So, I think we have some kind of a consensus and here is issue SLING-387
> [1] covering this change.
>
Looks good to me so far. But :) how are we handling the different search
path locations? Given that we search in /A and /V, is first /A searched
for possible script and only if there is none, /V is searched? Or is the
script search alternating between /A and /V?
I think this is missing in the description.

Carsten
--
Carsten Ziegeler
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Felix Meschberger-2
Hi,

Am Freitag, den 18.04.2008, 13:59 +0200 schrieb Carsten Ziegeler:

> Felix Meschberger wrote:
> > Hi,
> >
> > So, I think we have some kind of a consensus and here is issue SLING-387
> > [1] covering this change.
> >
> Looks good to me so far. But :) how are we handling the different search
> path locations? Given that we search in /A and /V, is first /A searched
> for possible script and only if there is none, /V is searched? Or is the
> script search alternating between /A and /V?

We must search both locations "at the same" time. I could imagine
something like:

 (1) find best match in /A (aka /apps)
 (2) find better match /V (aka /libs), otherwise use result of (1)

or more code-like:

   match = NIL;
   foreach (String path in resourceResolver.getSearchPath()) {
       newMatch = findMatch(path);
       if (match == NIL or newMatch isBetterThan match) {
           match = newMatch;
       }
   }

This would then be extended by adding another (outer) loop for resource
super type search:

   match = NIL;
   type = resource.getType();
   default = "sling/servlet/default";
   for (;;) {
       // selection
       match = innerLoop(type); // see above
       if (match != NIL) {
           break;
       }
       // endselection
       if (type == default) {
           break;
       }
       type = getResourceSuperType(type);
       if (type == NIL) {
         type = default;
       }
   }

This outer loop only scans the resource super types and default type if
there is no match in earlier loops.

Alternatively we could have the outer loop also behave like the inner
loop: go up the resource super type chain and finally the default type
all the time and only at the end we have the best match. The code for
the selection bracket would then be:

       // selection
       newMatch = innerLoop(type); // see above
       if (match == NIL or newMatch isBetterThan match) {
           match = newMatch;
       }
       // endselection

Not sure, whether this makes sense, though.

Probably about time for a prototype implementation ?

> I think this is missing in the description.

It is.

Regards
Felix


Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Bertrand Delacretaz
On Fri, Apr 18, 2008 at 2:54 PM, Felix Meschberger <[hidden email]> wrote:

>  Am Freitag, den 18.04.2008, 13:59 +0200 schrieb Carsten Ziegeler:
>  >...Given that we search in /A and /V, is first /A searched
>  > for possible script and only if there is none, /V is searched? Or is the
>  > script search alternating between /A and /V?
>
>  We must search both locations "at the same" time. I could imagine
>  something like:
>
>   (1) find best match in /A (aka /apps)
>   (2) find better match /V (aka /libs), otherwise use result of (1)...

XSLT uses a numeric priority scheme to handle such things, we could
probably use something similar: find scripts in both locations,
compute their numeric priorities, use the best match or complain
(probably only a warning) if there's a tie.

See http://www.w3.org/TR/xslt#conflict for inspiration.

-Bertrand

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Felix Meschberger-2
Hi,

Am Freitag, den 18.04.2008, 14:59 +0200 schrieb Bertrand Delacretaz:

> On Fri, Apr 18, 2008 at 2:54 PM, Felix Meschberger <[hidden email]> wrote:
> >  Am Freitag, den 18.04.2008, 13:59 +0200 schrieb Carsten Ziegeler:
> >  >...Given that we search in /A and /V, is first /A searched
> >  > for possible script and only if there is none, /V is searched? Or is the
> >  > script search alternating between /A and /V?
> >
> >  We must search both locations "at the same" time. I could imagine
> >  something like:
> >
> >   (1) find best match in /A (aka /apps)
> >   (2) find better match /V (aka /libs), otherwise use result of (1)...
>
> XSLT uses a numeric priority scheme to handle such things, we could
> probably use something similar: find scripts in both locations,
> compute their numeric priorities, use the best match or complain
> (probably only a warning) if there's a tie.
>
> See http://www.w3.org/TR/xslt#conflict for inspiration.

I was in fact thinking of calculating a weight value for each script
path and take the one with the greatest value. But I think, it is
probably even better to make use of the Comparable interface (or
Comparator depending on the actual implementation) and be able to just
compare two objects representing the scripts and using the "higher" one.

Regards
Felix


Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Bertrand Delacretaz
On Fri, Apr 18, 2008 at 3:16 PM, Felix Meschberger <[hidden email]> wrote:

> ... I was in fact thinking of calculating a weight value for each script
>  path and take the one with the greatest value. But I think, it is
>  probably even better to make use of the Comparable interface (or
>  Comparator depending on the actual implementation) and be able to just
>  compare two objects representing the scripts and using the "higher" one....

Makes sense, that will make the decision process fine-grained and
easier to follow.

-Bertrand

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Carsten Ziegeler
In reply to this post by Felix Meschberger-2
Felix Meschberger wrote:

> Hi,
>
> Am Freitag, den 18.04.2008, 14:59 +0200 schrieb Bertrand Delacretaz:
>> On Fri, Apr 18, 2008 at 2:54 PM, Felix Meschberger <[hidden email]> wrote:
>>>  Am Freitag, den 18.04.2008, 13:59 +0200 schrieb Carsten Ziegeler:
>>>  >...Given that we search in /A and /V, is first /A searched
>>>  > for possible script and only if there is none, /V is searched? Or is the
>>>  > script search alternating between /A and /V?
>>>
>>>  We must search both locations "at the same" time. I could imagine
>>>  something like:
>>>
>>>   (1) find best match in /A (aka /apps)
>>>   (2) find better match /V (aka /libs), otherwise use result of (1)...
>> XSLT uses a numeric priority scheme to handle such things, we could
>> probably use something similar: find scripts in both locations,
>> compute their numeric priorities, use the best match or complain
>> (probably only a warning) if there's a tie.
>>
>> See http://www.w3.org/TR/xslt#conflict for inspiration.
>
> I was in fact thinking of calculating a weight value for each script
> path and take the one with the greatest value. But I think, it is
> probably even better to make use of the Comparable interface (or
> Comparator depending on the actual implementation) and be able to just
> compare two objects representing the scripts and using the "higher" one.
>
Hmm, I know that we can cache the results, but isn't this too expensive?
  (First searching all configured paths - there could be more than two
and then use the best result).
For a given search path we have a well-defined search order for the
script (as outlined in the bug), so we make this the outer loop and the
inner loop iterates over the configured scripts. As soon as a script is
found, we can use that.

Carsten

--
Carsten Ziegeler
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Felix Meschberger-2
Hi,

Am Freitag, den 18.04.2008, 15:21 +0200 schrieb Carsten Ziegeler:

> > I was in fact thinking of calculating a weight value for each script
> > path and take the one with the greatest value. But I think, it is
> > probably even better to make use of the Comparable interface (or
> > Comparator depending on the actual implementation) and be able to just
> > compare two objects representing the scripts and using the "higher" one.
> >
> Hmm, I know that we can cache the results, but isn't this too expensive?
>   (First searching all configured paths - there could be more than two
> and then use the best result).
> For a given search path we have a well-defined search order for the
> script (as outlined in the bug), so we make this the outer loop and the
> inner loop iterates over the configured scripts. As soon as a script is
> found, we can use that.

We probably do not want to do that. Consider two scripts

    /apps/sling/sample/sample.esp
    /libs/sling/sample/sample.print.a4.esp

Now, we probably want to use the latter script and not the first one
because the latter is more specific to the request.

I agree, that today, the former script (sample.esp) is in fact selected.
But this is probably wrong. And it is probably such a strange case, that
noone stumbled upon it for now. But nevertheless, I consider today's
behviour wrong.

Regarding cost: The cost incurrence we have to do a full check is a
child listing per search path entry and some string operations on each
entry. This is opposed to today where we have child list entries per
selector (if we have selectors), though we might not completely walk all
listings.

So, even though we do more on the child listings, we have less listings.

I think, this is probably bearable ... But request logger might show
more or even some performance analysis.

Regards
Felix


Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Carsten Ziegeler
Felix Meschberger wrote:

> Hi,
>
> Am Freitag, den 18.04.2008, 15:21 +0200 schrieb Carsten Ziegeler:
>>> I was in fact thinking of calculating a weight value for each script
>>> path and take the one with the greatest value. But I think, it is
>>> probably even better to make use of the Comparable interface (or
>>> Comparator depending on the actual implementation) and be able to just
>>> compare two objects representing the scripts and using the "higher" one.
>>>
>> Hmm, I know that we can cache the results, but isn't this too expensive?
>>   (First searching all configured paths - there could be more than two
>> and then use the best result).
>> For a given search path we have a well-defined search order for the
>> script (as outlined in the bug), so we make this the outer loop and the
>> inner loop iterates over the configured scripts. As soon as a script is
>> found, we can use that.
>
> We probably do not want to do that. Consider two scripts
>
>     /apps/sling/sample/sample.esp
>     /libs/sling/sample/sample.print.a4.esp
>
> Now, we probably want to use the latter script and not the first one
> because the latter is more specific to the request.
Yepp, exactly that's what I meant in my description, so my suggestion is
to look for (leaving out all other posibilities):
      /libs/sling/sample/sample.print.a4.esp
      /apps/sling/sample/sample.print.a4.esp
      /libs/sling/sample/sample.esp
      /apps/sling/sample/sample.esp

The first search already succeeds, we're finished.

>
> I agree, that today, the former script (sample.esp) is in fact selected.
> But this is probably wrong. And it is probably such a strange case, that
> noone stumbled upon it for now. But nevertheless, I consider today's
> behviour wrong.
Yes, me, too. That's why I asked for a description :)

>
> Regarding cost: The cost incurrence we have to do a full check is a
> child listing per search path entry and some string operations on each
> entry. This is opposed to today where we have child list entries per
> selector (if we have selectors), though we might not completely walk all
> listings.
>
> So, even though we do more on the child listings, we have less listings.
>
> I think, this is probably bearable ... But request logger might show
> more or even some performance analysis.
Hmm, ok, I mean we can start with the simplest impl and improve later
on, but I think that the "use the first match" algorithm should be the
fastest.

Carsten
--
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 Felix Meschberger-2
On Fri, Apr 18, 2008 at 3:45 PM, Felix Meschberger <[hidden email]> wrote:

> ...Consider two scripts
>
>     /apps/sling/sample/sample.esp
>     /libs/sling/sample/sample.print.a4.esp
>
>  Now, we probably want to use the latter script and not the first one
>  because the latter is more specific to the request....

Agree with you, unless we want to give priority to /libs over /apps,
which is how search paths work in unixish file systems.

>  ...I think, this is probably bearable ... But request logger might show
>  more or even some performance analysis....

We can profile that code once we have it if needed, but I doubt this
will be very relevant to the overall performance of processing a
request. And if it is, as we said before, those decisions are easy to
cache.

-Bertrand

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Felix Meschberger-2
In reply to this post by Carsten Ziegeler
Hi,

Am Freitag, den 18.04.2008, 15:53 +0200 schrieb Carsten Ziegeler:

> Felix Meschberger wrote:
> > Hi,
> >
> > Am Freitag, den 18.04.2008, 15:21 +0200 schrieb Carsten Ziegeler:
> >>> I was in fact thinking of calculating a weight value for each script
> >>> path and take the one with the greatest value. But I think, it is
> >>> probably even better to make use of the Comparable interface (or
> >>> Comparator depending on the actual implementation) and be able to just
> >>> compare two objects representing the scripts and using the "higher" one.
> >>>
> >> Hmm, I know that we can cache the results, but isn't this too expensive?
> >>   (First searching all configured paths - there could be more than two
> >> and then use the best result).
> >> For a given search path we have a well-defined search order for the
> >> script (as outlined in the bug), so we make this the outer loop and the
> >> inner loop iterates over the configured scripts. As soon as a script is
> >> found, we can use that.
> >
> > We probably do not want to do that. Consider two scripts
> >
> >     /apps/sling/sample/sample.esp
> >     /libs/sling/sample/sample.print.a4.esp
> >
> > Now, we probably want to use the latter script and not the first one
> > because the latter is more specific to the request.
> Yepp, exactly that's what I meant in my description, so my suggestion is
> to look for (leaving out all other posibilities):
>       /libs/sling/sample/sample.print.a4.esp
>       /apps/sling/sample/sample.print.a4.esp
>       /libs/sling/sample/sample.esp
>       /apps/sling/sample/sample.esp

/apps comes before /libs (this is a detail)

>
> The first search already succeeds, we're finished.

Factually, this is correct. Implementationwise we will not do it like
this. Because we do not know the script extension beforehand, we cannot
use direct access. We have to scan the child lists anyway.

Regards
Felix

>
> >
> > I agree, that today, the former script (sample.esp) is in fact selected.
> > But this is probably wrong. And it is probably such a strange case, that
> > noone stumbled upon it for now. But nevertheless, I consider today's
> > behviour wrong.
> Yes, me, too. That's why I asked for a description :)
>
> >
> > Regarding cost: The cost incurrence we have to do a full check is a
> > child listing per search path entry and some string operations on each
> > entry. This is opposed to today where we have child list entries per
> > selector (if we have selectors), though we might not completely walk all
> > listings.
> >
> > So, even though we do more on the child listings, we have less listings.
> >
> > I think, this is probably bearable ... But request logger might show
> > more or even some performance analysis.
> Hmm, ok, I mean we can start with the simplest impl and improve later
> on, but I think that the "use the first match" algorithm should be the
> fastest.
>
> Carsten


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,

Am Freitag, den 18.04.2008, 15:54 +0200 schrieb Bertrand Delacretaz:

> On Fri, Apr 18, 2008 at 3:45 PM, Felix Meschberger <[hidden email]> wrote:
>
> > ...Consider two scripts
> >
> >     /apps/sling/sample/sample.esp
> >     /libs/sling/sample/sample.print.a4.esp
> >
> >  Now, we probably want to use the latter script and not the first one
> >  because the latter is more specific to the request....
>
> Agree with you, unless we want to give priority to /libs over /apps,
> which is how search paths work in unixish file systems.

The search path from ResourceResolver.getSearchPath defines the order.
And this is currently configured to be [ "/apps", "/libs" ], thus giving
precendence to /apps over /libs. This is correct as we assume provided
scripts in /libs and application "overwrites" in /apps.

Regards
Felix

>
> >  ...I think, this is probably bearable ... But request logger might show
> >  more or even some performance analysis....
>
> We can profile that code once we have it if needed, but I doubt this
> will be very relevant to the overall performance of processing a
> request. And if it is, as we said before, those decisions are easy to
> cache.
>
> -Bertrand


Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Carsten Ziegeler
In reply to this post by Felix Meschberger-2
Felix Meschberger wrote:
>> The first search already succeeds, we're finished.
>
> Factually, this is correct. Implementationwise we will not do it like
> this. Because we do not know the script extension beforehand, we cannot
> use direct access. We have to scan the child lists anyway.
>
Ah, right, didn't think about the script extension, sorry.

Carsten

--
Carsten Ziegeler
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Carsten Ziegeler
In reply to this post by Felix Meschberger-2
Felix Meschberger wrote:
>
> The search path from ResourceResolver.getSearchPath defines the order.
> And this is currently configured to be [ "/apps", "/libs" ], thus giving
> precendence to /apps over /libs. This is correct as we assume provided
> scripts in /libs and application "overwrites" in /apps.
>
Btw, shouldn't we prefix these dirs to make it clear that they are for
sling? Like "sling:libs" and "sling:apps" ?

Carsten

--
Carsten Ziegeler
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Felix Meschberger-2
Hi,

Am Freitag, den 18.04.2008, 16:22 +0200 schrieb Carsten Ziegeler:
> Felix Meschberger wrote:
> >
> > The search path from ResourceResolver.getSearchPath defines the order.
> > And this is currently configured to be [ "/apps", "/libs" ], thus giving
> > precendence to /apps over /libs. This is correct as we assume provided
> > scripts in /libs and application "overwrites" in /apps.
> >
> Btw, shouldn't we prefix these dirs to make it clear that they are for
> sling? Like "sling:libs" and "sling:apps" ?

They are not reserved for sling. These directories are part of the
search path used by the Sling Servlet/Script Resolver to resolve all
scripts, regardless of whether they are sling or not.

Hence, we need not (and probably must not) prefix them.

Regards
Felix


Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Carsten Ziegeler
Felix Meschberger wrote:

> Hi,
>
> Am Freitag, den 18.04.2008, 16:22 +0200 schrieb Carsten Ziegeler:
>> Felix Meschberger wrote:
>>> The search path from ResourceResolver.getSearchPath defines the order.
>>> And this is currently configured to be [ "/apps", "/libs" ], thus giving
>>> precendence to /apps over /libs. This is correct as we assume provided
>>> scripts in /libs and application "overwrites" in /apps.
>>>
>> Btw, shouldn't we prefix these dirs to make it clear that they are for
>> sling? Like "sling:libs" and "sling:apps" ?
>
> They are not reserved for sling. These directories are part of the
> search path used by the Sling Servlet/Script Resolver to resolve all
> scripts, regardless of whether they are sling or not.
Hmm, yes, that's right. Having scripts in /apps and /libs where /libs
has precendence of /apps still feels not very intuitive for me. So I
would rather put them under /scripts/apps etc. But on the other hand
these dirs could contain different stuff as well (resources etc.).
As there's no need to change it, let's keep it as it is :)

Carsten

--
Carsten Ziegeler
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Felix Meschberger-2
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.

Regards
Felix


Reply | Threaded
Open this post in threaded view
|

Re: Simplifying script paths and names?

Carsten Ziegeler
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]

123