cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ru...@us.ibm.com
Subject Re: Pipeline conditional model
Date Thu, 01 Jun 2000 15:02:46 GMT


Stefano Mazzocchi wrote:
>> Looking at it from a drawing lines between boxes perspective, a more
>> straightforward approach is to put the conditions on the lines.  The
>> XML equivalent would be:
>>
>>    <serializer type="wap" when="response gt 1.5KB" />
>>    <serializer type="xml" when="response le 1.5KB" />
>
>Good suggestion.
>
>> For more complex cases, you can factor out the computation of the
boolean
>> expression into a separate XML structure, and only allow reference of
the
>> result here.  Similar to <available> in Ant.
>
>Can you make an example?

Sure.  Let me start with a bad (in the sense that does not present the
proposal in the most flattering light) example.  This is from your original
mailing on the subject:

  <process uri="*">
   <if test="user belongs-to allowed-users"/>
    <generator type="parser" src:local="*"/>
    <if test="browser supports wap">
     <filter type="xslt" srl:local="stylesheet/2wml.xsl"/>
     <if test="response bigger-than 1.5Kb">
      <serializer type="splitted-wap"/>
     </if>
     <else>
      <serializer type="xml"/>
     </else>
    </if>
    <else-if test="browser wants pdf"/>
     <filter type="xslt" srl:local="stylesheet/2fo.xsl"/>
     <serializer type="fo2pdf"/>
    </else-if>
    <else>
     <filter type="xslt" src:local="stylesheet/2html.xsl">
     <serializer type="html"/>
    <else>
   </if>
   <else>
    <resource name="Error Page"/>
   </else>
  </process>

Here is a first pass at factoring out the conditions:

  <states>
    <condition name="legal"  test="user belongs-to allowed-users"/>
    <condition name="tooBig" test="legal and response bigger-than 1.5Kb"/>
    <condition name="wapOK"  test="legal and browser supports wap"/>
    <condition name="pdfOK"  test="legal and browser wants pdf"/>

    <condition name="sendErr"   test="not legal" />
    <condition name="sendWAP"   test="wapOK and not tooBig"/>
    <condition name="sendXML"   test="wapOK and tooBig"/>
    <condition name="sendPDF"   test="wapOK and pdfOK"/>
    <condition name="sendXSLT"  test="wapOK and not pdfOK"/>
  <states>

  <process uri="*">
    <generator  when="legal"    type="parser" src:local="*"//>
    <filter     when="wapOK"    type="xslt" srl:local="stylesheet/2wml.xsl"
 />
    <serializer when="sendWAP"  type="splitted-wap"/>
    <serializer when="sendXML"  type="xml"/>
    <filter     when="sendXSLT" type="xslt"
srl:local="stylesheet/2fo.xsl"/>
    <serializer when="sendPDF"  type="fo2pdf"/>
    <filter     when="sendHTML" type="xslt"
src:local="stylesheet/2html.xsl"/>
    <serializer when="sendHTML" type="html"/>
    <resource   when="sendErr"  name="Error Page"/>
  </process>

First general observations:

1) From a Turing point of view, you lose no functionality.

2) I readily concede that the <if/> approach scales UP better - i.e., can
handle flow patterns of arbitrary complexity better.  The above is an
example of a moderately complex flow.  I would argue that if you are faced
with anything more complicated than the above, you should hire a real
programmer and implement a custom processor for your application in a
"real" programming language.

3) I would argue that the "when=" approach scales DOWN better - simple
conditions are handled in a more natural and intuitive fashion.

4) Then DTD for the "when=" approach is considerably simpler.

5) Conceptually, there still is a pipeline of processors, just diverters of
arbitrary complexity which can be snapped on at any stage in the pipeline.

6) Both approaches are visually constructable.

Now a few suggestions:

1) I still think people have their own predilections when it comes to which
syntax they find more natural for expressions.  Allowing a language= on the
condition statements would widen the appeal.  My vote for the default is
JavaScript as it appeals to web designers and Java programmers alike.
Unfortunately, JavaScript makes use of "<", ">", and "&" characters.
Defining or picking a new language without these problems may be valuable.

2) The name "states" is probably too computer-science-ish.  Valves,
diverters, relays, or the like may be more fitting analogies.

3) I defined a bunch of random states in my example.  A common paradigm is
mutually exclusive choices (the last 5 in my example).  Allowing a
<choice><condition>*</choice> to appear any place a <condition> can
in the
DTD, where every choice implicitly contains a "... and not any of the
choices that preceded me" would simplify usage.

- Sam Ruby



Mime
View raw message