Return-Path: <balld@webslingerZ.com>
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 90770 invoked from network); 18 Jun 2000 20:30:01 -0000
Received: from balld-0.dsl.speakeasy.net (HELO localhost.localdomain)
 (@216.254.77.75)
  by locus.apache.org with SMTP; 18 Jun 2000 20:30:01 -0000
Received: from localhost (balld@localhost)
	by localhost.localdomain (8.9.3/8.9.3) with ESMTP id PAA00972
	for <cocoon-dev@xml.apache.org>; Sun, 18 Jun 2000 15:20:29 -0400
X-Authentication-Warning: localhost.localdomain: balld owned process doing -bs
Date: Sun, 18 Jun 2000 15:20:29 -0400 (EDT)
From: Donald Ball <balld@webslingerZ.com>
X-Sender: balld@localhost.localdomain
To: cocoon-dev@xml.apache.org
Subject: Re: sitemap draft still needs work in the matcher/chooser area
In-Reply-To: <394C0435.518F27B4@apache.org>
Message-ID: <Pine.LNX.4.10.10006181451340.882-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

On Sun, 18 Jun 2000, Stefano Mazzocchi wrote:

> Donald Ball wrote:
> > 
> > Welp, I had a few minutes last night to poke around cocoon2. Daunted by
> > the size of the sitemap coding task ahead of us
> 
> It's not that bad after all.

yeah, well, the rate of progression of the code belies that myth.

> > However, it doesn't do much since I'm not sure how to address a
> > couple of issues yet:
> > 
> > 1. where should do site or directory-specific configuration of components?
> > take the AuthenticationMatcher, for instance. An obvious implementation
> > would be the FileAuthenticationMatcher. How do I know where to look for
> > the file? The only place in the current sitemap draft where I'm allowed to
> > configure matchers in in the declaration of components block - but suppose
> > I want to have different files for different directories?
> 
> this is where sitemap mounting should help, sort of .htaccess
> equivalent. 
> 
> But I'm open to suggestions, of course.

hmm. not sure if i made myself clear. okay, suppose we have a chooser
which relies on a resource from the filesystem - call it the FoobarChooser
to avoid any more fights about doing user auth. i want to have the chooser
use two different files in different parts of the map. we don't have a
syntax for that right now. how about this:

<choosers>
 <chooser type="foobar" src:class="org.apache.cocoon.tester.FoobarChooser">
  <param name="src" value="/usr/local/etc/foobar.xml"/>
 </chooser>
</choosers>

<pipeline>
 <choose type="foobar">
  <param name="src" value="/home/balld/etc/foobar.xml"/>
  <when test="foobar('bat')">
   <generator/>
   <serializer/>
  </when>
  <otherwise>
   ...
  </otherwise>
 </choose>
</pipeline>

that covers the multiple configuration problem. now suppose i wanted to
use a relative path in the src parameter - what would it be relative to?
the sitemap in which the param element appears? could we use xml:base?

> > 2. exactly how is the choose/when stuff supposed to work? i see that the
> > type attribute of the choose tag indicates which chooser is assigned to
> > test the condition, but what happens then? should the chooser API look
> > something like this:
> > 
> > boolean choose(Request request, String test);
> 
> no
> 
>   Map xxx(CocoonRequest request, String test);
> 
> where
> 
>   Map is a collection of key-value pairs
>   xxx is the name of the test ("default" is the default one)
>   Request the CocoonRequest that comes to Cocoon
>   test the "test" attribute of the "when" element
> 
> for example:
> 
>  <choose type="uri">
>   <when test="/docs/*">
>   </when>
>   <when test="regexp('...')"/>
>   </when>
>  </choose>
> 
> then you have
> 
>  public class URIChooser implements Chooser {
>   Map default(CocoonRequest request, String test) {
>     // perform wildcard matching filling the map with matched tokens
>     if (matched)
>      return tokenMap;
>     else
>      return null;
>   }
> 
>   Map regexp(CocoonRequest request, String test) {
>     // perform regexp matching filling the map with matched tokens
>     if (matched)
>      return tokenMap;
>     else
>      return null;
>   }
>  }

I'm afraid I don't get the Map thing. How would it work for a simple
boolean test like FoobarChooser does?

> > where test is the value of the test attribute of the when element? what
> > form are the test expressions allowed to take? 
> 
>  test="..." for the default method
> 
>  test="xxx('...')" for the xxx method
> 
> note this poses some parsing problems that we might easily solve with
> 
>  <when method="..." test="...">
> 
> where the "default" method is IMPLIED if not expressed.

er, well, that might make calling methods with multiple parameters a bit
trickier...

> > they look an awful lot like XPath expressions to me... :)
> 
> What do you suggest?

you _know_ what i suggest - that we actually use XPath for real here.
Construct a virtual DOM (with callbacks, not actually filled in) with all
of the request-time information, provide handy global variables for
commonly used stuff (browser, etc.) and let sitemap authors write XPath
expressions in their sitemaps:

<choose>
 <when test="$browser='netscape' and $language='en'">
  ...
 </when>
</choose>

i stopped arguing about it, but still, the more i think about it, the more
i think this approach makes more sense than what i currently see in the
sitemap working draft.

- donald