cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: RFC: Logic TagLib
Date Thu, 11 Jan 2001 20:26:24 GMT
Jeremy Quinn wrote:

> Dear Cocooners,
> 
> 
> I develop XSP TagLibs, as part of my work on the CRUDLET project.
> 
> 
>         <http://www.crudlet.org>
> 
> 
> We have developed a draft proposal of a TagLib for handling "content 
> logic" for webapps; to allow contextual content selection logic to be 
> encoded in an XSP page without the user having to write Java Code inside 
> <xsp:logic/> tags.

First, let me say you did a good job.  Next, let me offer a few constructive
criticisms.  I like the idea of conditional logic for a higher-level
programming interface--but it seems so XSL centric.  I realize that for
those of us who use XSL extensively, that we find very creative ways of
making things happen.  However XSL is also very verbose.  This carries
over to your logic logicsheet.

Many developers are migrating from something like JSP, ColdFusion, ASP,
or something similar.  I am more familiar with ColdFusion, so I will use
that as an example:

Colfusion allows illegal syntax, so I will give it in cfml and xml:

<cfif variable.foo eq "bar">
   <p>Foo is a Bar</p>
<cfelse>
   <p>Foo is not a Bar</p>
</cfif>

Now the XMLised version:

<logic:if parameter="variable.foo" eq="bar">
   <p>Foo is a Bar</p>
   <logic:else>
     <p>Foo is not a Bar</p>
   </logic:else>
</logic:if>

Both versions are IMO more readable.  Here are the notes:

the parameter is scoped (from CFML carry over) by different
levels: variable, session, uri, form, application.  I actually
find this to be a bit too fine grained.  It would be done better
like this: request, session, variable (with variable being
default scope).

the operation is an attribute whitch is more readable to the
average programmer.  Possible attributes and attribute combos
follow:

eq (equals)
lt (less than)
gt (greater than)
ne (not equal to)
lte (less than/equal to)
gte (greater than/equal to)
from to (between FROM and TO inclusive)

Now for the choose tag:

<cfswitch expression="form.type">
   <cfcase value="dogcow">
     This is a Dogcow.
   </cfcase>
   <cfcasedefault>It was non of the above</cfcasedefault>
</cfswitch>

and in XML:

<logic:switch expression="request.type">
   <logic:case eq="dogcow">
     This is a Dogcow.
   </logic:case>
   <logic:default>It was none of the above</logic:default>
</logic:switch>

This are more analogous to many more true programming languages.

The expressions can become more complex--but would need more
analysis than what I can lend here.

> 
> 
> This is something that was critical for our project to allow us to 
> develop in a more scaleable way to the techniques we are using now.
> 
> 
> The Logic TagLib was designed to be generic it has no dependencies on 
> the CRUDLET project, it was always intended to be contributed to Cocoon.
> 
> 
> 
> We invite all interested parties to read and comment on the proposal.
> 
> 
>         <http://www.crudlet.org/logicTaglib.html>
> 
> 
> I understand that some people may find this controversial .... I am not 
> too worried, we know it is something we need ;) but I am interested in 
> your opinions and I am totally prepared to alter the specification, or 
> to not incorporate it into Cocoon or whatever, depending on the response.
> 
> 
> 
> As a taster, here are two examples from the proposal:
> 
> 
> A simple test for equality between the value that arrived in the request 
> parameter called "blag" and an empty String. If the parameter was empty, 
> the TextNode "The request param is empty" is output to the parent 
> element of the <logic:if/> tag; otherwise there is no output.
> 
>        <logic:if>
>               <logic:test op="eq">
>                     <logic:arg><request:get-parameter 
> name="blag"/></logic:arg>
>                      <logic:arg/>           
>                 </logic:test>
>            <logic:then>The request param is empty</logic:then>
>      </logic:if>    
> 
> This is a typical use of the <logic:choose/> tag whereby multiple 
> <logic:when/> clauses are evaluated until one of them returns something. 
> If none of them returned anything, the contents of <logic:otherwise/> is 
> output. There should be one or more <logic:when/> clauses and only one 
> <logic:otherwise/>. The equivalent forms of nesting available to the 
> <logic:if/> tag will also work with the <logic:choose/> tag.
> 
>     <logic:choose>
>           <logic:when>
>                     <logic:test op="eq">
>                             <logic:arg><request:get-parameter 
> name="type"/></logic:arg>
>                              <logic:arg>fish</logic:arg>
>                      </logic:test>
>                    <logic:then>This is a Fish</logic:then>
>         </logic:when>
>            <logic:when>
>                     <logic:test op="eq">
>                             <logic:arg><request:get-parameter 
> name="type"/></logic:arg>
>                              <logic:arg>dogcow</logic:arg>
>                    </logic:test>          
>                         <logic:then>This is a Dogcow</logic:then>
>                </logic:when>
>            <logic:otherwise>It was none of the above</logic:otherwise>
> 
>         </logic:choose>
> 
> 
> 
> 
> This will get implemented over the coming weeks.
> 
>  
> 
> Let me know what you think, (but please read the whole thing first ;)
> 
> 
> Thanks
> 
> 
> regards Jeremy
> 
> -- 
>    ___________________________________________________________________
> 
>    Jeremy Quinn                                           Karma Divers
>                                                        webSpace Design
>                                             HyperMedia Research Centre
> 
>    <mailto:sharkbait@mac.com>                <http://www.media.demon.co.uk>
>     <phone:+44.[0].20.7737.6831>        <pager:jermq@sms.genie.co.uk>



Mime
View raw message