Saturday, October 8, 2005, 8:13:15 AM, Jason Pettiss wrote:
> It's an interesting question... I guess it's a tradeoff between syntax
> stability and error robustness. The former favors smart users who are
> used to dealing with the absolutes imposed by programming languages, the
> latter, artsy-fartsy types who honestly have trouble terminating html
> elements properly.
I'm not sure I understand what you mean. Which variation is for the
artsy-fartsy types? Because I say they are who need something that is
stupid-simple and damn strict. Because otherwise they will bungle the
templates all the way... Unlike a sophisticated programmer, who will
enjoy if he can do smart abbreviations like $foo instead of ${foo},
while he will not shoot itself on foo.
> JSP for example has absolute delimiters which are glaring (and ugly).
> You get one of those wrong, your whole page breaks fantastically, and
> without a nice error system or checking the logs, you won't know where
> the problem is. Taglibs just make things worse because in a page that's
> designed to generate HTML they hide really well... and still even one
> mistake and BOOM! Developers dislike it, artists fear it...
>
> Velocity needs just a single character most of the time, and it's very
> tolerant of mistakes.
That's actually rather a problem than a good feature. If I made mistake
I *want* a big error page into my face, rather than the error to hide.
Because if I have made a mistake then I have buggy template... hence it
should be fixed, right? Especially I want it for the "artsy-fartsy
types" because they *will* do a lot of mistakes, so let the template
engine help them by pointing out the mistakes, because they don't see it
themselves. If the template engine tries to suppress errors, that's a
maintenance and quality assurance nightmare.
That JSP has ugly error pages... well, yes, that's a problem. BUT that's
not the question of the language design, that's the problem of the
currently widely used implementations. If you design a new template
language, just let assume you will not be that lame and can output
helpful error messages, "Dude, you have forgotten to close the tag
with %> at line 10, column 5 (<%if x === 1...etc.). Will you?"
> Most of the time it'll spit out a full page and the non-technical user
> can see exactly where they screwed up, and why.
Will they? If the error has really prominent effect 99% yes... But not
all errors are prominent (or even visible with certain input data
(context)). But if there is somewhere a $windowName.close() or
#elseWHITE literally printed in the middle of the markup, especially
into an attribute value or CSS that is not displayed directly... (Not to
mention the non-syntax related problem of an #if where the condition
always evaluates to false because of a typo like #if(usreLoggedIn)... I
just mention it because it's something related to strict VS loose error
handling approach.) And then consider later quick modifications to the
templates during maintenance, when the only checking is a quick look at
new output by a single people.
> This makes it very friendly for the user, and intuitive for most
> purposes, but at the expense of having an absolute way to escape and
> delimit...
But really, why is it friendly that if I write #forecah instead of
#foreach, then it will not be an error? I mean, this is what computers
are good at and people are bad at... finding stupid-mindless formal
mistakes like this. And then the computer doesn't help me? Yes, of
course I know why is it friendly. People likes to sweep problems under
the carpet. Ostrich policy. But I really belive it's a foolish habit of
people, and at the end they just lose with it. (It's bit like people
don't like those people who tell their mistakes into their face... they
rather like nice guys who always smile, no mater what.)
> which means sometimes the mechanism breaks down. Typically
> this is just a minor annoyance to a non-technical user, who most of the
> time doesn't grasp the difference between dynamic and static content
> anyway-- and so is using trial and error, and will do so here, to get
> over the little stumbling blocks imposed by a very liberal syntax.
There is some irony in calling a syntax to liberal because it has no
clear delimiters. Because, liberty means that you are free to do
something that you otherwise (if there is no liberty) you could not. And
what is that thing? Bungling templates without getting error. Well... I
don't know how is it in other countries, but it's a lot of analogy with
ultra-liberal political parties here: they want to let people do
whatever obviously bad, injurious thing. But nonetheless many people
want to do those things, so ultra-liberals are popular. Just,
popular != good.
> Due to the lack of reliable escaping, Velocity would break down entirely
> if the page being generated were, say... oh I dunno... another Velocity
> template! Fortunately this is highly uncommon and I don't think it's
> the intention of the language. Velocity also isn't well suited for
> strict content where whitespace and newlines really matter-- like
> certain WML--
No template language can be too good at that... Simply, the basic idea
of a template languages is incompatible with strict white-space control.
> but then again, JSP is pretty terrible at this too. As a
> general purpose template language in a world awash with XML and HTML
> lookalikes, Velocity does well. If the web were composed of shell
> scripts I am sure it wouldn't be as well accepted.
The thing why template engines with template engines syntax is much much
more important question that with other languages: it has to work well
together with another syntax. Now if what's the good template syntax
depends on what that other syntax is. But, there are template syntaxes
that are good almost for everything, like Template Toolkit's [% ... %]
for example. Still, obviously a template engine that is specialized on,
say, Java Language, will be the better for that than a more general
purpose template engine syntax. Life is full of dilemmas... I tend to
think that a template engine ideally should support multiple syntaxes.
> I do think there's got to be a way to get the flexibility and liberal
> syntax in the 90% scenario, yet have a way to reliably escape, delimit,
> control whitespace conventions, etc, in the "other" cases. Also-- the
> template language I want also lets me choose the syntax markers and
> define them in the content. Then all I have to do is choose delimiters
> which don't appear that often in the page, and I'm always basking in the
> sunny 90% scenario... ;-)
>
> About the macro-with-body... that's really just two macros on either
> side of some content, isn't it?
No. Consider (with a hypothetical template language):
<@macro foo>
<@local x>
<@set x = 1>
<@doBody />
<@set x = x + 1>
<@doBody />
${x} <@-- 2 -->
</@macro>
What I meant to show is that you go back to the caller's context with
the <@doBody />, but still didn't lost the local context and whatever
local state (like the last instruction) of the foo macro. It can be very
convenient. Also, you was able to chose if for how many times do you
execute the body. Here it was executed twice (but most commonly it's
about conditionally not execution it at all or executing it once).
> Its nice to not have to remember to "close", but you have to do that
> with for loops and if statements and comments anyway, right?
Right, but what's then? You still want to do it your macros as well.
> --jason
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
