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.
Agreed.
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, http://marc.theaimsgroup.com/?t=109941988300003&r=1&w=2
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
