cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <pati_giac...@yahoo.com>
Subject Re: Squaring the sitemap circle...
Date Fri, 26 May 2000 09:02:16 GMT
Stefano Mazzocchi wrote
> 
> Ross Burton wrote: 
> > 
> > Can matchers be nested? 
> 
> Well, to be honest, I don't know. At first it seems as FS, but we had
> the same discussion for the JAMES sitemap (yes, people, JAMES will
> have an sitemap very similar to this!) and I agreed that nestable 
> matching is a good thing. 

Serialized matchers incorporate OR logic, nested matchers AND logic, right?

> 
> > Do we want to state that matchers return the document when the
> > matcher has been applied, or should there be a <return/> tag to send 
> > the data to the client, so that matcher tags can be smaller? I'm 
> > just not sure there is enough logic in the matcher syntax, if we can 
> > represent if () {...} else if () {...} else {...} I'll be extremely
> > happy. 
> 
> the need for a "default" matcher emerged and I agree that the syntax 
> above can lead to problems for users thinking that the <generator> at
> the end is executed no matter what. 
> 
> Possible solutions are: 
> 
>   <process uri="*"> 
>      <match type="load" greater-then="2.5"> 
>          <generator type="parser" src="./*.xml" /> 
>          <filter type="xslt" src="./stylesheet/low-graphics.xsl" /> 
>          <serializer type="html" /> 
>      </match> 
>      <match type="browser" is="Mozilla5"> 
>          <generator type="parser" src="./*.xml" /> 
>          <filter type="xslt" src="./stylesheet/xul-enabled.xsl" /> 
>          <serializer type="html" /> 
>      </match> 
>      <otherwise> 
>       <generator type="parser" src="./*.xml" /> 
>       <filter type="xslt" src="./stylesheet/general-browser.xsl" /> 
>       <serializer type="html" /> 
>      </otherwise> 
>   </process> 
> 
> which can be rewritten less verbosely as 
>    
>   <process uri="*"> 
>     <generator type="parser" src="./*.xml"/> 
>     <match type="load" greater-then="2.5"> 
>      <filter type="xslt" src="./stylesheet/low-graphics.xsl"/> 
>     </match> 
>     <match type="browser" is="Mozilla5"> 
>      <filter type="xslt" src="./stylesheet/xul-enabled.xsl"/> 
>     </match> 
>     <otherwise> 
>      <filter type="xslt" src="./stylesheet/general-browser.xsl"/> 
>     </otherwise> 
>     <serializer type="html"/> 
>   </process> 
> 
> is this readable enough for everybody? 

Yes, the fact is, that the pipeline is not ended because of the matcher, it ends because of
the
serializer. Your example above shows exactly that. Because of that I still prefer the original
proposal without a <otherwise> or a <case>..</case> around them. Otherwise
I will propose to
rename the <match> to <when> to be consistent with usual programming languages.
But I see the need
for something like a default case if none of the matchers match. I also see that a <match
type="default"> will have us to define it as a component. Can we discuss about "builtin"
components, not necessarily being listed in the component definition section of the sitemap?

> > What exactly happens here: <mount uri="bugs/*" 
> > location="jar:./apps/bugs.cocoon#*" /> 
> 
> This indicates that every request that start with "bugs/" will be
> mapped to the web application contained into the "bugs.cocoon" jar 
> archive (extention doesn't matter, it could be any zipped file). 
> 
> The -only- constraint (like for any other mounting) is that there
> must be a file called /WEB-INF/sitemap.xml located in the zipped file. 
> (WEB-INF like for Servlet 2.2 WAR archives) 
> 
> If this file is found, the sitemap is "merged" into the original one
> and the component definitions are cascaded. 

What happens if the sitemap.xml is not found? Does cocoon 2 sent a error  message, or delivers
that resource as a static file (or sends a redirect there to leave MINE type handling to the
web
server)?

>   
> > I'm happy to work on rewriting the image serializers to use this
> > sitemap and 
> > anything else I can do after the 3rd. 
> 
> Don't count on having this implemented soon. This is a working 
> suggestion on how it should be, but I think we'll move incrementally 
> from what we have today until we covered up all the functionality 
> described here rather than doing a major rewrite... 
> 
> =====
> --
> 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
> 
> __________________________________________________
> Do You Yahoo!?
> Kick off your party with Yahoo! Invites.
> http://invites.yahoo.com/


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

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

Mime
View raw message