cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@media.demon.co.uk>
Subject Re: RFC: Logic TagLib
Date Fri, 12 Jan 2001 12:18:49 GMT
At 15:26 -0500 11/01/01, Berin Loritsch wrote:
>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.

Thanks

>Next, let me offer a few constructive criticisms.

Even better ;)

>I like the idea of conditional logic for a higher-level
>programming interface--but it seems so XSL centric.

This pattern was chosen on purpose for it's familiarity.

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

I agree, it looks very verbose, however when I actually write real pages
with it (to sample the language, it's not implemented yet) it does not seem
so verbose when it is negotiating real content as opposed to little strings.

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

OK, I am not familiar with these products.

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

I don't see this as being so flexible.
It cannot test values from source other than the ones it has been
pre-programmed to know about, request, session etc.

If I wanted to test the value returned by

	<crudlet:var name="blah"/>
or
	<crudlet:value-of property="SatPublicOffers.InsuredValueIsNeg" bean="Offer"/>
or
	Some other TagLib (tm)
The logic engine would have to "know" about them.

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

Using these

>lte (less than/equal to)
>gte (greater than/equal to)

Do people prefer "LTE" to "LE" and "GTE" to "GE"?

>from to (between FROM and TO inclusive)

Nice idea, I might call this operator "range"?

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

It looks nice and compact.

Hmm, my choice of putting everything (except the Operator) in Elements,
makes it more verbose, I agree, but it allows you to work with any value,
including dynamic values from arbitrary sources.

We would not be able to do the job, with your suggested pattern of TagLib,
unfortunately.

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


Thank you for your feedback.


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