cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy G. Biv" <>
Subject Re: [RT] Formatting and Macros: A tangent on the template/taglib discussion
Date Sun, 05 Dec 2004 02:01:05 GMT
Thank you for the reply.  I realize that I'm trying your patience.  I 
appreciate you bearing with me.

Daniel Fagerstrom wrote:

> Roy G. Biv wrote:
>> 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?

Point 4: JXTG does it already.  Basically it amounts to saying what went 
wrong and what line/column the error in the template occurred on.

Point 7: I was referring to data formatters.  Sorry about that.

>> 1. Making a turing complete programming language out of the template 
>> language
> Things to avoid:
> 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?

It means I would try to stop thinking as a programmer and focus on the 
problem.  I know that seems in contradiction on its face since no matter 
what, we're dealing with a computer.  But I know for myself, I've spent 
so much time with C/C++/Java/Perl/Javascript that if, else, foreach, 
while, switch, etc. are all part of my natural language.  I like many 
many others on this list think in code.  The distinction between a class 
constant and an instance variable is clear and distinct on an almost 
instinctive level due to years of repetition.  "Singleton" and "facade" 
are in our daily vocabulary.

*We as programmers are odd.*

When designing template languages for example, I try to think as someone 
who hasn't taken an introductory programming or data structures class in 
college.  I try to think of my friends who think of if, else, while, 
etc. as just a few arbitrary words out of thousands in the English 
language.  Then add only what logic is necessary to get to a 
well-defined target.  Since if, else and foreach are all general 
programming directives, I consider their presence in a template language 
suspect until proven otherwise necessary.  Nothing nefarious or 
complex.  Just a reflex so that I can empathize with the target audience.

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

I guess I'm coming from the point of view of the samples for JXTG -- not 
the most complex material to work with.  Then again, that's the type of 
thing that I think of when I hear the term "template macro".  With the 
calendar example, I found the complexity to be the bean and the raw 
template directives necessary to iterate that bean.  The macro expansion 
portion never occured to me to be anything but the most trivial portion 
of the equation.

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

Haha!  Sorry about that.

>> 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, 
> all the 78 posts are not about that but many are ;)

Ahhhh...  This makes it clear for me.  This also explains why I missed 
the discussion.  I may just be slow, but I never considered that email 
subject line to be about JXTG template replacements.  I have been in 
general quite pleased with CForm work thus far and saw no need to get 
involved with implementation discussions about it.  I'm working my way 
through the discussion now to catch up.

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

Reading and catching up now.

- Miles Elam

View raw message