cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: RFC: Logic TagLib
Date Fri, 12 Jan 2001 11:29:15 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.
> 
> 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>

I'll be honest: I don't like XMLized scripting languages as a general
rule.

It blurs the separation of concerns: who is going to use this syntax? a
programmer? a document writer?

Having a procedural programming language included into your page as
another namespace appears more elegant than having a scriplet or
something like that, but it's nothing different conceptually.

Cocoon should aim at keep separation well defined and avoid unnecessary
blurring.

Let's keep the example above: it is the programmer concern to handle the
error case where the request parameter is empty, *NOT* the
document/template writer's. 

Do we want to create a scripting language using XML as a syntax? why? I
see this as FS big time!

The above should be written as

 <mylogic:do-something>
  <request:get-parameter name="blah"/>
 </mylogic:do-something>

which should take into account all the errors. What about the error
string? Right, it should be the writer's concern so we place it here

 <mylogic:do-something>
  <mylogic:message name="empty-param" xml:lang="en">
   The request param is empty.
  </mylogic:message>
  <mylogic:blah>
   <request:get-parameter name="blah"/>
  </mylogic:blah>
 </mylogic:do-something>

and the contract with the document writer is simply the schema that
"mylogic" namespace has. 

So, general anti-pattern: when you see <if>, <else>, <for> or even worse
<goto> beware: you are turning a declarative syntax into a procedural
semantic. And yes, even XSLT is somewhat too procedural in many parts.

Disclaimer: this is my personal opinion only and I have no voting right
at this moment so you decide what to do.

My feeling is that people will start small and end up asking for an XML
rewrite of their favorite programming language, which is pretty scary,
don't you think?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


Mime
View raw message