cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Small note on sitemap configuration
Date Thu, 01 Jun 2000 19:21:58 GMT
Donald Ball wrote:
> On Thu, 1 Jun 2000, Stefano Mazzocchi wrote:
> >    <when test="machine-load gt 1.0">
> >     <filter type="parser"
> > src="./foo/styles/style-{round-to-integer(machine-load)}.xsl"/>
> >    </when>
> >    <otherwise>
> >     <filter type="parser" src="./foo/styles/normal-style.xsl"/>
> >    </otherwise>
> >   </choose>
> >   ...
> >  </process>
> >
> > I don't think you could make such thing pass the (now infamous)
> > "Stefano's girlfriend test".
> >
> > But I admit I'm not 100% sure about all this....
> I'm certainly not either. Let's step back for a second and see what we
> agree on. The sitemap author should be able to write the sitemap in such a
> way as to...
> 1. choose different resolver (pipeline? is that your name for my object?)
> components depending on request-time information

yes, we've always being calling it "pipeline".

Yes, pipelines shoud be choosen at request-time information given URI +
state, where state is a function of request parameter and everything
else in this world.
> 2. configure difference resolver components with request-time information

No, I don't think we need this.

Since the state is passed anyway to the components (all
generator/filter/serializer components have access to the CocoonRequest,
CocoonResponse and all Composers to Cocoon itself)
> do you agree with these assertions? if so, then we're pretty close in our
> visions. 

The problem is that I don't agree with point 2. I think it's -not- a
sitemap concern.

> i'm simply saying that a sitemap that allows conditionals based
> on something like this:
> <process uri="whatever">
>  <matcher type="browser" value="explorer">
>   <matcher type="language" value="en">
>    <generator type="file" src="explorer.xml">
>   </matcher>
>   <matcher type="language" value="it">
>    <generator type="file" src="">
>   </matcher>
>  </matcher>
>  <matcher type="browser" value="lynx">
>   <matcher type="language" value="en">
>    <generator type="file" src="lynx.xml">
>   </matcher>
>   <matcher type="language" value="it">
>    <generator type="file" src="">
>   </matcher>
>  </matcher>
> </process>
> That's hella-cumbersome, and doesn't factor out the conditionals very
> well. My strategy would let you rewrite it like this:
> <process>
>  <choose>
>   <when test="$language='en'">
>    <generator type="file" src="{$browser}.xml"/>
>   </when>
>   <when test="$language='it'">
>    <generator type="file" src="{$browser}.{$language}.xml"/>
>   </when>
>  </choose>
> </process>
> I think that's much easier to understand and write. 

I think

 <process uri="**">
  <generator test="lang-browser-file" src="**"/>

is much easier to understand and write :)

> Sure, you can get
> yourself into trouble if you move too much logic inside the sitemap and
> out of your XSP pages or whatever. So what? I prefer to have the extra
> rope, even if I might accidentally hang myself.

I have two main concerns:

1) once you start this programmatic road, pretty sure people will ask
for <for> loops, procedures and all that stuff. I've seen this happening
for Ant. I think there is an evident sign already, we _don't_ need such
complexity, not even the variables.

2) this requires you to think! Sure, I can't force you to think, but
it's good to try.


Java avoiding multiple inheritance. That's the best ever.

Have you ever wanted multiple inheritance? I did. Badly. It forced me to
go to my whiteboard and layout my OO strategy. Now I don't anymore
because I saw the problem and my design improved.

Careful, a sitemap with no variables is, to me, the exact equivalent.
You should _not_ place logic into the sitemap... by creating variables
and run-time parameters.... it would soon make the sitemap too complex
to handle.

On the other hand, I do see the need for such a thing.... it's another
of those things I need more feedback to evaluate....

The problem is that once we add it and people start using it, we can't
remove it later on. So we must decide if this is FS or not _before_
placing it in.

Send your comments, folks.

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