cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] Formatting and Macros: A tangent on the template/taglib discussion
Date Sun, 05 Dec 2004 00:34:43 GMT
Roy G. Biv wrote:
> Here's where I'm at on templates.  Feel free to critique.
> 
> Goals (in order of importance):
> 1. Get data from an object model
> 2. Minimize or eliminate programmatic logic inside the template
> 3. Make as simple to read/write templates as possible
> 4. Give feedback on all possible errors
> 5. Make the data presentable -- follow established Java data formatting 
> rules where possible
> 6. Speed
> 7. Allow extensibility without altering core code

Seem reasonable. Point 4. seem complicated, care to expand on this. 
Concerning point 7., I'm curious, wasn't you in strong oposition against 
extensibillity?

> Things to avoid:
> 1. Making a turing complete programming language out of the template 
> language

The important point is not Turing compatibility, BTW I woudn't think 
that the attribute language I proposed it Turing compatible.

The important things is IMO, that the language is side effect free and 
and has access to the things but not more. What that means is an 
important point to discuss. It is also important that the directives are 
so well designed so that it is easy to perform common tasks.

> 2. Avoid tags that simply duplicate programmatic language structures 
> (eg. <if> <else> <forEach>)

Is this a syntax or semantics question? I.e. does it mean that you think 
they are ok as attributes but not as tags or does it mean that you will 
rule out such constructs completely?

> 3. Second-guessing the data model (eg. getInt, getFloat, getString)

Agree.

> 4. Programmatic tag libraries for macros (ie. Just use STX, stx:include 
> and aggregate tranforms)

As said before I don't share your love for STX, I find it rather cool 
for applications where I need to do simple things for huge amount of 
repetetive data, but otherwise its far to complicated for my taste.

> While I doubt my goals will draw much criticism, the latter group may.  
> In my opinion, once you fall into if/else/forEach land, you've just 
> rewritten XSP with attribute markers instead of <xsp:logic> markers.  
> I'm probably a broken record here, but there is no difference between 
> <if test="x"/> and if(x){}.

Yes you are, so I try to avoid repeating my answer ;)

> In addition, I'm wondering what folks think of the following:
> 
> -----------------------------
> Template Typing/Formatting
> -----------------------------

Yes, what do we think? Take a look at: [RT] Attribute Rendering and 
CForms Convertors, http://marc.theaimsgroup.com/?t=109941988300003&r=1&w=2
all the 78 posts are not about that but many are ;)

<snip/>
> With this, formatting concerns are handled in code that's not intimately 
> tied to (and easily separated from) any particular sitemap component and 
> can reuse code not specifically made for Cocoon.

Yes, we are at the same page as you can see in the above thread. We 
found a solution that separated concerns some what better, but it's 
quite similar. Jonas have implemented a prototype of it, but its not 
included in svn yet.

> -----------------------------
> Macros
> -----------------------------
> 
> I strongly encourage the use of STX stylesheets for this.  Let's say you 
> have the following markup from the JXTG samples:
> 
>  <table>
>    <tablerows list="${greatlakes}" color="blue"/>
>  </table>
> 
> I'd prefer using an alternate namespace, but I digress.  You make a STX 
> stylesheet with the relevant protion:
> 
>  <stx:template match="tablerows">
>    <jx:forEach var="item" items="{@list}">
>      <tr><td bgcolor="{@color}">${item}</td></tr>
>    </jx:forEach>
>  </stx:template>
> 
>     or with attribute syntax
> 
>  <stx:template match="tablerows">
>    <tr jx:forEach="item in {@list}"><td 
> bgcolor="{@color}">${item}</td></tr>
>  </stx:template>

Why not just:

<tr do="macro(tablerows,list,color);forEach($list)">
   <td bgcolor="{$color}">${item}</td>
</tr>

or

<jx:macro name="tablerows">
   <jx:parameter name="list"/>
   <jx:parameter name="color"/>
   <jx:forEach var="item" items="{$list}">
     <tr><td bgcolor="{$color}">${item}</td></tr>
   </jx:forEach>
<jx:macro>

why do you want to use an external language for the macro expansion, it 
should be enough with learning the template language for writing macros.

> This is what is happening after all whether in Java or not, isn't it?  
> Anyone want to tell me that this is harder and requires more knowledge 
> than writing, compiling and installing a Java class?

It seem to me that you believe that I or someone else have sugested that 
  macros like tablerow should be written in Java. If that is the case I 
can understand your frustration. But I cannot understand what you have 
got that idea from. I have most certainly never sugested anything even 
close to it. I would find it horible to write my webapps that way.

Java is needed for writing "if", "forEach" and a number of other core 
constructs, nothing else.

> With this, macro 
> languages can be far more dynamic and immediate to the problems at hand; 
> syntactic sugar and simplification with no fear of side effects.

> There you have your modular, maintainable macro library.  STX when used 
> in this manner is sufficiently fast, not overly complex, uses very 
> little memory (SAX-based), and is highly cacheable.  This is why I don't 
> like the idea of this type of thing going into full, programmatic 
> logic.  A Java interface behind macros strikes me as an overly complex 
> solution and not as easy to edit/maintain as the stylesheet method.

<snip/>

Miles, it seem that you propose things that are very close to things 
that I and others have discussed the design for in previous e-mails. If 
there are things that I fail to explain in a clear way it would be 
better if you just asked what I mean instead of assuming the worst.

/Daniel

Mime
View raw message