cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Squaring the sitemap circle...
Date Thu, 25 May 2000 10:59:45 GMT
"Timm, Sean" wrote:
> 
> Stefano Mazzocchi [mailto:stefano@apache.org] wrote:
> 
> >I spent two complete days to write a sitemap that embeds all the points
> >above. There are some weak points (mainly authentication issues) where I
> >need some feedback, but there are _many_ new design patterns that I
> >introduced by simply writing the more elegant schema I would like to
> >work with.
> 
> *Very* nice.  I have a couple of questions.  In the following snippet, is
> it just assumed that if it doesn't match that it follows the resource?
> Could it just as easily be a generator/filter/serializer combo?
> 
> <process uri="restricted/*">
>   <match type="user" belongs-to="administrators">
>     <generator type="parser" src="./restricted/*" />
>     <filter type="xslt" src="./stylesheets/restricted.xsl" />
>     <serializer type="html" />
>   </match>
>   <resource name="Access refused" />
> </process>
> 
> This seems a bit unclear to me...I guess I'd rather see a default matcher
> if no other matcher was successful.  Something like the following:
> 
> <process uri="restricted/*">
>   <match type="user" belongs-to="administrators">
>     <generator type="parser" src="./restricted/*" />
>     <filter type="xslt" src="./stylesheets/restricted.xsl" />
>     <serializer type="html" />
>   </match>
>   <match type="default">
>     <resource name="Access refused" />
>   </match>
> </process>

Well, it's more or less the equivalent of

 if (test) {
   do1();
   return;
 }
 do2;

against

 if (test) {
   do1();
 } else {
   do2();
 }

I agree that in Java the second is cleaner, but for XML, I didn't want
to declare a fake matching element to do that.

But I'm open to suggestions, I just don't like to _break_ the pattern
where 

 <match type="default">

means that I need a 

 <match type="default" class="...."/>

above.

> I assume that resource can be specified in any process uri.  However, is it
> possible to refer to a resource in another XML file?  Something like the
> following:
> 
> <match type="language">
>   <resource name="Access refused"
> location="resources.xml#xpointer($language/resources[0])" />
> </match>

Hmmm, interesting vision, didn't think of that... sort of
called-templates for XSLT...
 
> (Okay...maybe XPointer is a bit extreme, but it would be cool.)  So this
> example would use
> a language matcher to determine which language you preferred, and it would
> pull the
> appropriate resource from the resources.xml file based on that language.
> ($language would
> be replaced with the appropriate language identifier...)  I haven't had to
> work with
> internationalization issues before, so I could be completely
> misunderstanding something
> here, but this just seems cool.
> 
> Irregardless, I would like to be able to pull resources from a separate
> file.

Well, <resource> is nothing more than a placeholder for groups of
elements that are used often. We could well use internal XInclude
instead, it's a redundant element functionality-wise.

So what you want to do is simply

 <match type="language" is="IT">
  <resource name="Access Refused (italian)"/>
 </match>
 <match type="language" is="EN">
  <resource name="Access Refused (english)"/>
 </match>
 <resource name="Access Refused (italian)">
   <generator type="parser" src="./error/it/access-refused.xml" />
   <filter type="xslt" src="./stylesheets/restricted.xsl" />
   <serializer type="html" />
 </resource>
 <resource name="Access Refused (english)">
   <generator type="parser" src="./error/en/access-refused.xml" />
   <filter type="xslt" src="./stylesheets/restricted.xsl" />
   <serializer type="html" />
 </resource>

but I agree that if the matcher is able to pass variables....hmmmm....
 
> Anyway, this looks like a really cool direction for the sitemap, and I
> understand it in this
> form better than I did the last form.  Great job, Stefano!

Thanks.

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



Mime
View raw message