cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: sitemap draft still needs work in the matcher/chooser area
Date Sat, 17 Jun 2000 23:05:25 GMT
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.

> I nonetheless decided to start writing some code. 
> I decided to tackle the matcher components, since
> they're well-defined and straightforward, and Stefano and I had a huge
> disagreement about them a couple of weeks ago. What better way to enforce
> my world view than to be the implementor? No one argues with working code
> ;)

what a kid :)
> Anyway, I just checked in the smidgen of code I wrote (Stefano, bless his
> heart, _just_ changed the name from matcher to chooser in the sitemap
> draft).

eh, eh, eh :)

Anyway, I do agree that "chooser" is kind of a silly, I'll let you guys
decide the name for this.

> 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

But I'm open to suggestions, of course.

> 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);


  Map xxx(CocoonRequest request, String test);


  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 test="regexp('...')"/>

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;
     return null;

  Map regexp(CocoonRequest request, String test) {
    // perform regexp matching filling the map with matched tokens
    if (matched)
     return tokenMap;
     return null;

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

> they look an awful lot like XPath expressions to me... :)

What do you suggest?

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

View raw message