cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: sitemap draft still needs work in the matcher/chooser area
Date Mon, 19 Jun 2000 10:13:25 GMT
Donald Ball wrote:
> 
> 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.

The rate of progression of the code depends on two months lost because
of process faults and many other problems it's not fair to list here
that go well beyond code length of complexity.

Besides, I remind you I haven't touched the C2 codebase yet.
 
> > > 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?

Good point.... sheesh, the loader namespace doesn't work "inside
attributes"... should we get back to URL encoding instead?
 
> > > 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?

  final static public Map true = new MapImpl();
  final static public Map false = null;

  if (matched)
   return true;
  else
   return false;

Admittedly not super-elegant, but how do we do tests and pass tokens to
the pipeline?

Should we peparate "choosers" and "param tokenizers"?

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

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

hmmmm

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

Ok, let us suppose we do this. How do we extend this virtual request
schema, if needed?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message