cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <Giacomo.P...@pwr.ch>
Subject Re: Small note on sitemap configuration
Date Wed, 31 May 2000 23:02:42 GMT
Donald Ball wrote:
> 
> On Wed, 31 May 2000, Stefano Mazzocchi wrote:
> 
> >
> > Careful: this is a very dangerous path.
> >
> > True, we could virtually embed request information into a schema, but
> > what about _any_ state information? server name, machine load, time of
> > the day in Australia, density of population in antartica, local
> > temperature, number of subscribed people to the cocoon-dev mail list, an
> > so on...
> >
> > Do you _really_ want to write a schema (or RDFSchema, for that matter)
> > for all that? I don't think so :)
> 
> I strongly disagree here. We're going to have to present the sitemap
> author with some way to access request-time information in their
> conditionals, right? Whatever scheme we use, we're going to have to limit
> it to the request-information that is likely to be relevant (e.g. all
> information about the request itself and a little bit about local state -
> current time, etc.) So saying that allowing access to request-time
> information via XPath expressions is a bad idea because we could overload
> it with too much information is fatuous. The same criticism can be
> levelled at any method of allowing access to request-time information.
> 
> Go back to my language example:
> 
> <process uri="/foo/**">
>  <choose>
>   <when test="language">
>    <generator type="parser" src="./foo/{language}/**"/>
>   </when>
>   <otherwise>
>    <generator type="parser" src="./foo/en/**"/>
>   </otherwise>
>  </choose>
>  ...
> </process>
> 
> How would you propose to rewrite this example using your matcher elements?
> 
> > -1 on the use of XPath as testing logic (for the problems outlined
> > above).
> >
> > You might want to look into the "Pipeline Conditional Model" thread and
> > comment on what I proposed there.
> 
> I don't see anything in that proposal about accessing the value of
> request-time variables in the configuration of the resolver components -
> which I think is key. I don't see any problems with XPath expressions that
> don't apply equally well to anything else that accomplishes the same goal.
> Maybe I have missed something though?

Just a quick thought about this. What if we have a
"SitemapPropertyManager" class (I don't want to call it a Component)
that is responsable for resolving {variable}? A default version could
implement request information. If someone has special needs he could
subclass, extend or make his own to have such properties available.

Giacomo

> 
> - donald

-- 
PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7                     Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen                    Web:   http://www.pwr.ch

Mime
View raw message