From giacomo@apache.org  Sun Nov  5 20:37:40 2000
Return-Path: <giacomo@apache.org>
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 28468 invoked from network); 5 Nov 2000 20:37:40 -0000
Received: from stargazer2.dataway.ch (HELO dataway.ch) (195.216.80.34)
  by locus.apache.org with SMTP; 5 Nov 2000 20:37:40 -0000
Received: (qmail 20846 invoked from network); 5 Nov 2000 20:37:22 -0000
X-dataway-Spamcheck: 195.216.80.154: RBL=- DUL=- RSS=- ORBS=-
Received: from unknown (HELO pwr.ch) (195.216.80.154)
  by stargazer.dataway.ch with SMTP; 5 Nov 2000 20:37:22 -0000
Received: (qmail 8139 invoked from network); 5 Nov 2000 19:33:25 -0000
Received: from unknown (HELO apache.org) (giacomo@10.20.30.106)
  by simba.pwr.ch with SMTP; 5 Nov 2000 19:33:25 -0000
Sender: giacomo
Message-ID: <3A05B688.42A91211@apache.org>
Date: Sun, 05 Nov 2000 20:35:36 +0100
From: Giacomo Pati <giacomo@apache.org>
Organization: Apache Software Foundation
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.16 i686)
X-Accept-Language: de-DE, de-CH, en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Better and Better and RT
References: <014b01c045e4$2a7c1990$bd00a8c0@infoplanning.com> <3A0406ED.4BD1A360@mail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

Ross Burton wrote:
> 
> Berin Loritsch wrote:
> >
> > With the latest CVS of Cocoon2, I noticed that all the
> > samples work as expected again.  I also noticed that
> > the plumbing is much quicker as well.  Sitemap generation
> > is roughly the same, however once generated the rest of
> > the resources compile 10-20% faster than before.
> >
> > (I know we aren't worried about performance yet, but it's
> > good to know it is improving none the less).
> >
> > I haven't tried dealing with the browser selector.
> >
> > I envision the following additional selectors to be vital
> > to any site:
> >
> > ParameterSelector (select things pased on HTTP parameters)
> > AcceptsSelector (send PNG to browsers that accept it...)
> 
> I have plans to write both of these.  I'm currently finishing a spec for
> BrowserCapabilitySelector which will include Accepts as a parameter, and
> IIRC a ParameterMatcher was posted recently which might be able to be
> changed to a selector.

Take into account that a Selector chooses between multiple possibilities
(and a default one if neither choosen) whereas a Matcher returns a List
(or maybe we should change that to a Map) of values you can use for
substitution in src attributes of Generators and Transformers. I can
imaging to have a Matcher that select values out of the environment
objects (Request/Response/Session/Context) and a corresponsing Selector
which chooses some component to generate the view expected. This way you
can still refer to the values the Matcher has evaluated.

  <match type="uri" pattern="myuri">
    <match type="value-extractor" pattern="unused">    <-----+
      <select type="value-selector">                         !
        <when test="first">                                  !
          <generate type="file" src="mydir/first/{value}/> --+
        </when>
        ...
      </select>
    </match>
  </match>

I really think that we must think in terms of "team play" between
components. What do you think about that?

Giacomo