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="[EMAIL PROTECTED]"> <tr><td bgcolor="[EMAIL PROTECTED]">${item}</td></tr> </jx:forEach> </stx:template>
or with attribute syntax
<stx:template match="tablerows">
<tr jx:forEach="item in [EMAIL PROTECTED]"><td bgcolor="[EMAIL PROTECTED]">${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
