cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Prevost <prev...@maya.com>
Subject Re: Squaring the sitemap circle...
Date Fri, 26 May 2000 06:11:55 GMT
>>>>> "sm" == Stefano Mazzocchi <stefano@apache.org> writes:

    sm> the need for a "default" matcher emerged and I agree that the
    sm> syntax above can lead to problems for users thinking that the
    sm> <generator> at the end is executed no matter what.

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

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

    sm> is this readable enough for everybody?

Hmm.  I think this would be better:

<process uri="*">
  <generator type="parser" src="./*.xml"/>
  <case>
    <match type="load" greater-than="2.5">
      <filter type="xslt" src="./stylesheet/low-graphics.xsl"/>
    </match>
    <match type="browser" equal-to="Mozilla5">
      <filter type="xslt" src="./stylesheet/xul-enabled.xsl"/>
    </match>
    <otherwise>
      <filter type="xslt" src="./stylesheet/general-browser.xsl"/>
    </otherwise>
  </case>
  <serializer type="html"/>
</process>

First, because greater-than is better than greater-then, and equal-to
is more like greater-than (and hence more consistent).  ;>

But more importantly, because it allows for the possibility of more
than one match case grouping in a row:

<process ...>
 <generator .../>
 <case>
  ...
 </case>
 <case>
  ...
 </case>
 <serializer .../>
</process>

In this example, one choice from the first case would run, then one
choice from the second case would run.  We could further add syntax
sugar to make:

<process ...>
 ...
 <match ...>
  ...
 </match>
 ...
</process>

where the match isn't in a case be equivalent to:

<process ...>
 ...
 <case>
  <match ...>
   ...
  </match>
 </case>
 ...
</process>

Which in my example would mean "if it matches do it, if not, don't".
So match on its own is equivalent to xsl:if, and match and otherwise
inside case are equivalent to xsl:when and xsl:otherwise inside
xsl:case.

As an example of how you might want to use this (now we get to see how
much I remember from your message yesterday without looking at it
again.):

<process uri="*">
 <case>
  <match type="load" greater-than="3.5">
   <generator type="parser" src="./pre-processed/*.xml"/>
  </match>
  <otherwise>
   <generator type="parser" src="./*.xml"/>
   <filter type="xslt" src="./logicsheet/blah.xsl"/>
   <filter type="xsp"/>
  </otherwise>
 </case>
 <case>
  <match type="load" greater-than="2.5">
   <filter type="xslt" src="./stylesheet/low-graphics.xsl"/>
  </match>
  <match type="browser" equal-to="Mozilla5">
   <filter type="xslt" src="./stylesheet/xul.xsl"/>
  </match>
  <otherwise>
   <filter type="xslt" src="./stylesheet/plain.xsl"/>
  </otherwise>
 </case>
 <serializer type="html"/>
</process>

The goal of the above is: normally, use Mozilla5 XUL or normal
stylesheets depending on the browser, and read from ./*.xml.  But if
the load goes above 2.5, we want to use the low-graphics sheet no
matter what browser.

But then, if the load is still high, and goes above 3.5, we also bail
on doing xsp work (which is going to a database or something and
provides neat dynamic stuff) and drop down to a static content only
site until things calm down a bit.

Sound reasonable?  Sounds reasonably complex.  :)

On the "naming things" warpath again, I noticed when looking back at
your original message (yes, I cheated) that you have:

<match type="ip-filter" allowed-address="...">
<match type="browser" accepts="...">
<match type="user" belongs-to="...">
<match type="load" greater-than="...">
<match type="browser" is="...">

This looks to me like another case of "the loaded class chooses what
attributes it can have", which is easy to code and pretty friendly,
but not so XMLish sometimes.  I'm almost starting to think that you
almost ought to be ripping XSL's expression syntax and conditionals
off completely here, and say:

<if test="allowed-address($ip-filter)">
<if test="accepts($browser, 'blah')">
<if test="belongs-to($user, 'group')">
<if test="$load &gt; 2.5">
<if test="$browser = 'Mozilla5'">

The above isn't a good choice of syntax, and I'm not entirely sure
what is, but with choices that are this free-form, I think you really
do start dropping into a place where a fuul expression syntax is
needed.  And that's not even counting the pain of creating halfway
complex logical expressions with nested match tags.


I say +1 to most of what I see in the sitemap, but 0 to the way the
match stuff works right now.  I apologize for not being able to come
up with a better proposal.


Hrm.  Okay, a slight proposal, but it still makes me feel icky.  You
could have match like:

<match type="foo" test="bar">
 ...
</match>

where foo gets to interpret bar however it pleases.  Hence:

<match type="ip-filter" test="allowed">
<match type="browser" test="accepts('...')">
<match type="user" test="member-of('...')">
<match type="load" test="&gt; 2.5">
<match type="browser" test="is('Mozilla5')">

But this is still a big mess--trying to integrate the expression
evaluation stuff from XPath might actually be easier.


John.


Mime
View raw message