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 <[EMAIL PROTECTED]>
> > 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
>
