You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Steve O'Hara <so...@pivotal-solutions.co.uk> on 2005/10/06 13:31:47 UTC
RE: [ANN] Viento - WHY?
Am I missing something here......??
There seems to be a whole load of template laguages springing up all
over the place that look very similar to Velocity, each claiming it
solves a view problem that Velocity doesn't.
I've always assumed that Velocity is a "work in progress" and
contributions from programmers that improve it are always welcome. So
why aren't these FreeMarker/Viento/TomDick&Harry developers contributing
to Velocity rather than creating yet another clone?
I don't have any axe to grind either way but it seems a little odd to
keep developing new code bases for essentailly the same thing. I'm all
for step changed developments, but as far as I can make out, most of
these other tools are just slight improvements on the original.
Can anyone enlighten me?
Steve
-----Original Message-----
From:
velocity-user-return-16791-sohara=pivotal-solutions.co.uk@jakarta.apache
.org
[mailto:velocity-user-return-16791-sohara=pivotal-solutions.co.uk@jakart
a.apache.org] On Behalf Of Adam Williams
Sent: 06 October 2005 04:41
To: Velocity Users List
Subject: [ANN] Viento
Hello.
Velocity is great. It can be used to template anything, and works
quite well. Well, except for inline Maps ;) We have been using it for
almost three years, and would never go back to JSP, JSF, or
String.format().
Alas, we have needs that it cannot meet. The Sails[1] Web2.0 Solution
is under refinement, part of which required a new template language:
extensibility built into the design, Java 1.5, blocks. It is called
Viento[2].
Since you folks know template languages real well, the Sails team
hopes that you might do us a favor. Check out Viento and let us know
what you think. Read up on it, browse the source, and catch the
Wind[3].
adam williams
creator, Sails
austin taylor
creator, Viento
[1] http://www.opensails.org
[2] http://www.opensails.org/sails/wiki/Viento
[3] Viento is a Spanish word meaning 'Wind' - the kind that moves
sailboats
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Steve O'Hara" <so...@pivotal-solutions.co.uk> writes:
That is what Open Source is all about. If anyone decides that a
project doesn't match your needs, feel free to spring your
own. Competition is good.
There has been a Velocity clone announced here a while ago and even
Velocity has been incepted at the very beginning as a WebMacro clone.
If someone wants to contribute to the Velocity core, feel free to join
us over at -dev. However, as some of the discussions on this list
might have illuminated; the priorities of some developers might be
different from the priorities of the main Velocity driving forces
(first Geir, now mainly Will).
So I can understand that people either fork or start all over. About
forking: The ASF license explicitly encourages that by just requiring
you to acknowledge from where you came ("This project uses Software
developed by the Apache Software Foundation") and not forcing you to
put all your changes back out in the open which might not even be
possible.
>Am I missing something here......??
No. IMHO.
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Daniel Dekany <dd...@freemail.hu>.
Thursday, October 6, 2005, 11:28:26 PM, Henning P. Schmiedehausen wrote:
> Daniel Dekany <dd...@freemail.hu> writes:
>
> The fact that you cut out the answer to your actual question and all the
> relevant arguments shows how much you are actually interested in that
> answer.
Just what are you talking about? Is this some strategy to wash away
anything relevant I happened to say by generating some *senseless* row?
While you are basically saying above that I'm doing something like that?
But I don't care what's the game here. So, you know what:
Dear Henning P. Schmiedehausen!
I have to admit: You win!
I confess that I'm a monster whose only goal is destruction, and
whatever sin. Especially, I try to undermine one of the most true
flowers of the Free (as speech) Software mentality, which is ASF.
Because I'm plain evil. And BTW fascist. And paranoid. No, didn't said
any of these, I just confess it voluntary, so please don't care to
answer.
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Jason Pettiss wrote:
> He was answering the question that was originally asked-- how come so
> many different template frameworks, why doesn't every developer just
> flock to one and we all work in one big happy template commune. And the
> answer should be obvious given the here.
Jason, I was asking Henning Schmiedehausen to clarify remarks that he
had made previously. Did he appoint you as his spokesperson?
> Everyone has an agenda. Some
> have an agenda to bitterly whine on other user lists about their project
> not being as popular as they want it to be. Others have an agenda to
> continue support software which is developed by the foundation they
> belong to under the licensing terms and software model they believe in,
> thus every point in the FAQ is relevant.
Every point, eh?
How about point 3 of the 19 points on the FAQ?
Q: Is the Apache Software Foundation (ASF) a corporation?
A: Yes, the ASF is a membership-based corporation registered in
Delaware, United States. It is intended to be a registered non-profit
charity, and in fact was given 501(c)(3) status by the U.S. Internal
Revenue Service. However, even if something happens that changes that
status, the ASF is still a not-for-profit enterprise.
That's relevant to something we were talking about? When Henning claimed
that Daniel Dekany "doesn't get it" was it something in point 3 that he
"doesn't get"?
How about point 6?
Q: Who are the members of the ASF?
A: The current list of ASF members may be found on the Web at
<http://www.apache.org/foundation/members.html>.
Henning specifically directed Daniel to reread this FAQ page because he
"doedsn't get it". Surely he didn't mean point 6, that Daniel doesn't
understand that? So which of the 19 points was he referring to? In what
way does Daniel presumably not understand the points in question?
Now, Jason, it's okay if you don't know. That's normal, you can't read
Henning's mind, can you? But doesn't that mean that you should just let
Henning answer the question?
Jonathan Revusky
--
FreeMarker project, http://freemarker.org/
>
> But I found this snippet from his email particularly useful relevant:
>
> --------------
> Can we please have an understanding, that this is the users list of
> the Velocity project of the Jakarta project of the Apache Software
> Foundation. It is intended as a forum where Velocity users can discuss
> about Velocity and ask questions and the contributors and committers
> try to answer these questions. It is __not__ an advocacy forum or a list
> to discuss if there are different solutions for the problem space that
> Velocity lives in. It is also not a feature comparisation or product
> promotion forum. There are general and advocacy lists inside the ASF
> where this behaviour is tolerated and even encouraged.
> --------------
>
> So bugger off, already.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Jason Pettiss <ja...@TheCatalis.com>.
He was answering the question that was originally asked-- how come so
many different template frameworks, why doesn't every developer just
flock to one and we all work in one big happy template commune. And the
answer should be obvious given the here. Everyone has an agenda. Some
have an agenda to bitterly whine on other user lists about their project
not being as popular as they want it to be. Others have an agenda to
continue support software which is developed by the foundation they
belong to under the licensing terms and software model they believe in,
thus every point in the FAQ is relevant.
But I found this snippet from his email particularly useful relevant:
--------------
Can we please have an understanding, that this is the users list of
the Velocity project of the Jakarta project of the Apache Software
Foundation. It is intended as a forum where Velocity users can discuss
about Velocity and ask questions and the contributors and committers
try to answer these questions. It is __not__ an advocacy forum or a list
to discuss if there are different solutions for the problem space that
Velocity lives in. It is also not a feature comparisation or product
promotion forum. There are general and advocacy lists inside the ASF
where this behaviour is tolerated and even encouraged.
--------------
So bugger off, already.
Jonathan Revusky wrote:
> Henning P. Schmiedehausen wrote:
>
>> Daniel Dekany <dd...@freemail.hu> writes:
>>
>> The fact that you cut out the answer to your actual question and all the
>> relevant arguments shows how much you are actually interested in that
>> answer.
>
>
> Well, I can't speak for Daniel, but I am kind of interested in trying
> to understand what point it is you're trying to make. So could you
> help me out here?
>
> On 30 September, you posted the following message:
>
>
> http://article.gmane.org/gmane.comp.jakarta.velocity.user/10233
>
> in which you say that Daniel just "doesn't get it". You suggested that
> he should re-read the document at:
>
> http://www.apache.org/foundation/faq.html
>
> There are 19 points in the FAQ there. I could not see how any of them
> had any relevance to what we were talking about. However, you did not
> mention which items you were referring to.
>
> On 1 October, I posted the following message:
>
> http://article.gmane.org/gmane.comp.jakarta.velocity.user/10238
>
> in which I asked you specifically to explain which of the 19 points
> you meant. I think it was a completely fair question that you really
> ought to answer, but you never deigned to respond. Could you please
> answer my question now? Which of the 19 points in the Apache FAQ were
> you referring to Daniel not understanding and how it is relevant to
> this overall discussion?
>
> Jonathan Revusky
> --
> freemarker project, http://freemarker.org/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Henning P. Schmiedehausen wrote:
> Daniel Dekany <dd...@freemail.hu> writes:
>
> The fact that you cut out the answer to your actual question and all the
> relevant arguments shows how much you are actually interested in that
> answer.
Well, I can't speak for Daniel, but I am kind of interested in trying to
understand what point it is you're trying to make. So could you help me
out here?
On 30 September, you posted the following message:
http://article.gmane.org/gmane.comp.jakarta.velocity.user/10233
in which you say that Daniel just "doesn't get it". You suggested that
he should re-read the document at:
http://www.apache.org/foundation/faq.html
There are 19 points in the FAQ there. I could not see how any of them
had any relevance to what we were talking about. However, you did not
mention which items you were referring to.
On 1 October, I posted the following message:
http://article.gmane.org/gmane.comp.jakarta.velocity.user/10238
in which I asked you specifically to explain which of the 19 points you
meant. I think it was a completely fair question that you really ought
to answer, but you never deigned to respond. Could you please answer my
question now? Which of the 19 points in the Apache FAQ were you
referring to Daniel not understanding and how it is relevant to this
overall discussion?
Jonathan Revusky
--
freemarker project, http://freemarker.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Daniel Dekany <dd...@freemail.hu> writes:
The fact that you cut out the answer to your actual question and all the
relevant arguments shows how much you are actually interested in that
answer.
Best regards
Henning
>Thursday, October 6, 2005, 7:33:53 PM, Henning P. Schmiedehausen wrote:
>[snip]
>>> Wait, I know! They wanted a J2EE implementation by which users can
>>> "win a 42'' Plasma HDTV or Sony(tm) PSP"? :) Ehhh, sorry, I have
>>> found it so funny... go to sf.net and see if you don't understand.
>>
>> This is exactly the kind of uninformed and snide remark that ridicules
>> you more than the people you try to put down.
>Wow wow wow! :) Man, what I said is factual, and not even a secret, and
>that some people (like me) will find the above mentioned Geronimo
>campaign a little bit funny/"perverted" is not a miracle IMHO. You seem
>to overreact... do you have bad conscience or what.
>> It actually shows how little you understand about the ASF and its
>> goals.
>Uhh.. ohh... sure. I Don't Get It! (TM) ;)
>--
>Best regards,
> Daniel Dekany
>---------------------------------------------------------------------
>To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: velocity-user-help@jakarta.apache.org
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Daniel Dekany <dd...@freemail.hu>.
Thursday, October 6, 2005, 7:33:53 PM, Henning P. Schmiedehausen wrote:
[snip]
>> Wait, I know! They wanted a J2EE implementation by which users can
>> "win a 42'' Plasma HDTV or Sony(tm) PSP"? :) Ehhh, sorry, I have
>> found it so funny... go to sf.net and see if you don't understand.
>
> This is exactly the kind of uninformed and snide remark that ridicules
> you more than the people you try to put down.
Wow wow wow! :) Man, what I said is factual, and not even a secret, and
that some people (like me) will find the above mentioned Geronimo
campaign a little bit funny/"perverted" is not a miracle IMHO. You seem
to overreact... do you have bad conscience or what.
> It actually shows how little you understand about the ASF and its
> goals.
Uhh.. ohh... sure. I Don't Get It! (TM) ;)
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Daniel Dekany <dd...@freemail.hu> writes:
>Or, Geronimo recently. You could ask: why they didn't contribute to
>JBoss or ObjectWeb's Jonas?
http://jboss.com/pdf/Why_We_Use_the_LGPL.pdf
http://jonas.objectweb.org/license.html
Because we care about free software. You might want to read up on this
one day. This is the main goal of the ASF from day one. Why do IBM,
Sun, BEA and all the other big players work with the ASF? Because they
care about free software.
> Wait, I know! They wanted a J2EE implementation by which users can
> "win a 42'' Plasma HDTV or Sony(tm) PSP"? :) Ehhh, sorry, I have
> found it so funny... go to sf.net and see if you don't understand.
This is exactly the kind of uninformed and snide remark that ridicules
you more than the people you try to put down. It actually shows how
little you understand about the ASF and its goals.
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Whitespace and Nitpicking
Posted by Will Glass-Husain <wg...@forio.com>.
We'll hit this eventually in Velocity. The problem is that we need the
behavior to be backwards compatible in the 1.x series. There's a proposal
to make this configurable, but that's tricky to do with javaCC. Right now
this is in JIRA scheduled for 2.x. Please feel free to contribute to the
Wiki discussion on this topic.
http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
and on JIRA
http://issues.apache.org/jira/browse/VELOCITY-253
WILL
----- Original Message -----
From: "Jason Pettiss" <ja...@TheCatalis.com>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: Saturday, October 08, 2005 1:23 PM
Subject: Re: Whitespace and Nitpicking
> Sometimes whitespace is critical and there is no generic filter which
> would know how to do the job. For HTML, I agree with you-- but remember
> Velocity is just a template language-- it can be used for many other
> purposes than generating HTML...
>
> Andrew Mason wrote:
>
>>Can I just make a quick point on the whole whitespace issue. Velocity
>>provides you with a couple of ways to handle your own output. For example
>>using String writers etc...I use a really nice set of classes called JTidy
>>for HTML output, you can run your output through that and create perfectly
>>tidy HTML (and valid if your designer isn't so talented). There is also
>>nothing to stop you from writing your own cleaner for other languages
>>where an implementation isn't already there. I can understand why people
>>want these features in velocity, Yes it would be handy, yes it should be
>>added as enough people want it, but I'm not sure it's as critical as many
>>people make it out to be (i could be wrong). You are given methods to
>>allow you to run the output through what ever classes you want. The only
>>time where this may not work is when your doing servlets with the old
>>VelocityServlet (i still don't use VelocityViewServlet yet so the option
>>maybe available in that too).
>>
>>
>>Andrew
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Whitespace and Nitpicking
Posted by Jason Pettiss <ja...@TheCatalis.com>.
Sometimes whitespace is critical and there is no generic filter which
would know how to do the job. For HTML, I agree with you-- but remember
Velocity is just a template language-- it can be used for many other
purposes than generating HTML...
Andrew Mason wrote:
>Can I just make a quick point on the whole whitespace issue. Velocity provides
>you with a couple of ways to handle your own output. For example using
>String writers etc...I use a really nice set of classes called JTidy for HTML
>output, you can run your output through that and create perfectly tidy HTML
>(and valid if your designer isn't so talented). There is also nothing to stop
>you from writing your own cleaner for other languages where an implementation
>isn't already there. I can understand why people want these features in
>velocity, Yes it would be handy, yes it should be added as enough people want
>it, but I'm not sure it's as critical as many people make it out to be (i
>could be wrong). You are given methods to allow you to run the output through
>what ever classes you want. The only time where this may not work is when
>your doing servlets with the old VelocityServlet (i still don't use
>VelocityViewServlet yet so the option maybe available in that too).
>
>
>Andrew
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Whitespace and Nitpicking
Posted by Mike Kienenberger <mk...@gmail.com>.
Not all output can be run through a cleaner.
One of the things I use Velocity for is to generate plain-text email.
It requires that I have complete control over line-breaks and output.
A general purpose templating language must have a known methodology
for generating whitespace. Velocity has one, but it's not
inituitive.
On 10/8/05, Andrew Mason <an...@assertis.co.uk> wrote:
>
> Can I just make a quick point on the whole whitespace issue. Velocity provides
> you with a couple of ways to handle your own output. For example using
> String writers etc...I use a really nice set of classes called JTidy for HTML
> output, you can run your output through that and create perfectly tidy HTML
> (and valid if your designer isn't so talented). There is also nothing to stop
> you from writing your own cleaner for other languages where an implementation
> isn't already there. I can understand why people want these features in
> velocity, Yes it would be handy, yes it should be added as enough people want
> it, but I'm not sure it's as critical as many people make it out to be (i
> could be wrong). You are given methods to allow you to run the output through
> what ever classes you want. The only time where this may not work is when
> your doing servlets with the old VelocityServlet (i still don't use
> VelocityViewServlet yet so the option maybe available in that too).
>
>
> Andrew
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Whitespace and Nitpicking
Posted by Daniel Dekany <dd...@freemail.hu>.
Saturday, October 8, 2005, 3:20:47 PM, Andrew Mason wrote:
>
> Can I just make a quick point on the whole whitespace issue. Velocity provides
> you with a couple of ways to handle your own output. For example using
> String writers etc...I use a really nice set of classes called JTidy for HTML
> output, you can run your output through that and create perfectly tidy HTML
> (and valid if your designer isn't so talented). There is also nothing to stop
> you from writing your own cleaner for other languages where an implementation
> isn't already there. I can understand why people want these features in
> velocity, Yes it would be handy, yes it should be added as enough people want
> it, but I'm not sure it's as critical as many people make it out to be (i
> could be wrong). You are given methods to allow you to run the output through
> what ever classes you want. The only time where this may not work is when
> your doing servlets with the old VelocityServlet (i still don't use
> VelocityViewServlet yet so the option maybe available in that too).
Sure, output with perfect white-space is certainly not achievable with a
general purpose text template languages (I mean without making the
templates horrible... lot of #* *# and like). They are inherently bad in
precisely control the white-space (WS from now), and since extra WS is
usually smaller problem that missing WS (at least in HTML/XML), they
rather output extra WS.
Still, there are some typical annoying superfluous WS generators, that
can be avoided with proper template language design. Like:
1
#if(foo)
2
#end
3
or
1
#foreach(x in cx)
- $x
#end
3
In these cases it's obvious that you don't want the line-break, nor the
indentation spaces in the lines of the directives. So this are cases
where a template engine could give much less superfluous white-space.
OK, just less, not no extra WS. But, if possible to output less, why
not...
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Whitespace and Nitpicking
Posted by Andrew Mason <an...@assertis.co.uk>.
Can I just make a quick point on the whole whitespace issue. Velocity provides
you with a couple of ways to handle your own output. For example using
String writers etc...I use a really nice set of classes called JTidy for HTML
output, you can run your output through that and create perfectly tidy HTML
(and valid if your designer isn't so talented). There is also nothing to stop
you from writing your own cleaner for other languages where an implementation
isn't already there. I can understand why people want these features in
velocity, Yes it would be handy, yes it should be added as enough people want
it, but I'm not sure it's as critical as many people make it out to be (i
could be wrong). You are given methods to allow you to run the output through
what ever classes you want. The only time where this may not work is when
your doing servlets with the old VelocityServlet (i still don't use
VelocityViewServlet yet so the option maybe available in that too).
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Jason Pettiss wrote:
> I have no disagreements with what you say. It isn't that content
> authors can't think-- it's that they don't think like programmers. For
> example, I have tried to show mine the merits of abstraction,
> encapsulation, generic utility... they just nod, disinterested. They
> have no need for it... for them the interesting challenge is not how to
> efficiently represent content, and as they type it out, their idle
> cycles aren't spent on modularizing, instead, they're thinking about
> colors, flow, layout.
Well, if you've presented these ideas to a graphical designer sort of
audience, and found that they were not interested, it may be that you're
not motivating the topic well. Designers probably won't be interested in
code modularity for its own sake.
Probably most designers -- well, the more clever ones anyway --
understand the advantage, for example, of gathering up various display
stuff in a style sheet and applying that one style sheet to all your
pages rather than putting <font...> tags everywhere. So, I think that
the refactorings we were talking about can be motivated in terms that
designers will understand -- the control of colors and fonts and so on.
It would be a question of finding the right way of presenting the idea.
> I'm not opposed to functionality. I just didn't
> need it for my purposes.
>
> And yes, taking the electric blue 486 over the boring looking 3 Ghz
> monster would be missing the point of the computer, but people do this.
Actually, most consumers out there are more informed than that.
I grant that consumers do in fact make final decisions on the grounds of
style and aesthetics, but I think that if you observe those cases, it
will be cases where the various product offerings were comparable
functionally.
When I buy a wristwatch, the main factor is aesthetic, but that is only
because I know that any watch I buy will keep reliable, accurate time.
> Some people will specifically not buy a car based on the lack of
> cupholders. Put a little green food coloring into your delicious batch
> of chocolate chip cookies and people won't be so eager to steal them
> when you're not looking.
>
> You gotta have the secondary aesthetics, at least for the adoption
> phase. The nice Mazda feature which makes the AC vents oscillate back
> and forth sold a lot of people-- even though they ended up turning it
> off after the first week, because it got annoying... purchasing
> decisions are almost always based on "feel-good" trivialities rather
> than strictly rational evaluation...
Well, the Mazda analogy is just a case in point. The automotive industry
is a much more mature space that computer software is. Mazda is
competing with offerings from other automakers that are broadly
comparable. So, given that the other things are functionally comparable,
to have a product with better style and aesthetics may well be what puts
one product over the top.
However, I still say that this can really only be the case when the
choices in the relevant market are broadly comparable *functionally*.
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
> Jonathan Revusky wrote:
>
>> Jason Pettiss wrote:
>>
>>> Hey, I agree with you. With a little more thinking, a little more
>>> up-front typing, you can make things readable and at the same time
>>> more concise. And inherently *better*. (Btw, the #assign feature is
>>> supercool.)
>>>
>>> Have you see the HTML written by content authors that aren't
>>> developers? Or worse-- what they produce when using the "aid" of a
>>> wysiwyg editor? They're not going to do all that super-nice stuff
>>> you used there-- because it doesn't appear "right" in their
>>> super-nifty editor... in fact until you add a framework to the
>>> template language which mock-evaluates the template in the wysiwyg
>>> editor, these extra features will just go to waste...
>>
>>
>>
>> Here, you're bringing up a real issue, but it is not specific to
>> FreeMarker. It's specific to any broadly similar templating tool.
>>
>> But also, there is an undercurrent in the above comments of yours that
>> I object to -- basically, one infers this idea that people who
>> primarily work with HTML, on the presentation layer, are dummies.
>> Something like:
>>
>> "Oh, that's a good feature you can use to encapsulate and clean up
>> your template code, but those people are too dumb to use it anyway."
>>
>> This kind of attitude makes me uncomfortable. Maybe it actually
>> overlaps with other kinds of things that I find troubling. How would
>> you react to something like:
>>
>> "No point spending money on a cultural center in a working class
>> neighborhood. Joe Six-Pack has no use for that kind of stuff anyway."
>>
>> I would object strenuously to the above kind of argument.
>>
>> But getting back to actual web development, I would be wary of
>> fostering an attitude that is contemptuous of the abilities of other
>> people on the team. It is probably quite true that front-end people
>> would not initially structure their pages very well, but that is
>> simply because they lack experience and nobody has got them started on
>> the right path to doing that.
>>
>> Anyway, as somebody deeply involved in developing this kind of tool,
>> all I can really do is provide the feature set that I think is
>> necessary. Some people will use the tool more effectively than other
>> people, no question.
>>
>>
>>>
>>> And until then, they'll just bitch and moan about the "extra" < / >
>>> all over the place.
>>
>>
>>
>> Well, people keep making claims like this, but that doesn't make it
>> true. The fact of the matter is that people who use FreeMarker to do
>> serious work are simply accustomed to the syntax and do not expend
>> energy moaning about what characters they have to type.
>>
>> Similarly, people who write code in Pascal-ish languages where blocks
>> are delimited by an explicit 'begin' and 'end' (unlike the { and } in
>> C-ish languages) do not spend their days moaning about having to type
>> begin and end. (Besides, you have heard of keystroke macros, right?)
>>
>> Finally, any such tool has to have some syntax or other. As a
>> practical matter, within reasonable bounds, people just get used to
>> whatever it is. Fairly quickly, probably, a few days at most.
>>
>>> And in most cases they're unnecessary anyway-- so why should I have
>>> to type them? You say that's a shallow question, but some languages
>>> do measure power by the savings of an extra character of syntax here
>>> and there, even at the expense of readability.
>>
>>
>>
>> Look, consider what you're saying for a second, you might step back
>> from it and consider: "Does this really make sense?"
>>
>> You can compare two things on aesthetic grounds, like one is prettier
>> than the other, when the two things are basically comparable
>> functionally. The Casio watch on my wrist, I would say that I bought
>> it solely because I liked how it looked. Why? Because any watch I
>> bought would keep the time accurately and reliably, so my choice would
>> just come down to style and aesthetics. And this may be the case with
>> something in a very mature product category, where anything you opt
>> for is basically very good on a purely *functional* level.
>>
>> However, if somebody offers you a new 3 Ghz Pentium 4 to put on your
>> desk that is an ugly shade of beige, and gives you as an alternative,
>> an old 486 that is a really nice electric blue color, you cannot
>> really opt for the 486.
>>
>> To base your decision on 2nd order aesthetic concerns can really only
>> make sense when the things you are comparing are broadly comparable
>> *functionally*.
>>
>> If you go look at blog entries where people talk about switching from
>> Velocity to FM, you see the people talking about functionality that
>> they are getting -- JSP taglib support, i18n support, a macro system
>> that's done properly -- and so on. One blog I know of, where a guy
>> stated a strong preference for Velocity, it was entirely because he
>> just likes the syntax better. (Or, one infers, it's the first one he
>> used, and he got used to the syntax...)
>>
>> http://weblog.flop.ca/2005/03/27/1111947748000.html
>>
>> But really, isn't it only reasonable to base your decision on
>> aesthetics if the things you're choosing between are comparable
>> *functionally*? Anything else is putting the cart before the horse.
>>
>> Jonathan Revusky
>> --
>> FreeMarker project, http://freemarker.org/
>>
>>
>>
>>
>>
>>> I just don't see why I should have to stroke the parser's ego with
>>> these extra characters, when it detracts from readability and isn't
>>> strictly necessary. I don't really care about having one right way
>>> as much as having the way that suits my needs at the present moment.
>>>
>>> --jason
>>>
>>> Jonathan Revusky wrote:
>>>
>>>> Jason Pettiss wrote:
>>>>
>>>>> Syntax highlighting isn't very flexible in many popular editors,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I haven't done a survey of this issue. Which editors are you
>>>> referring to specifically?
>>>>
>>>> Though, my honest reaction is that, I, personally, if I were writing
>>>> in language FOOBAR as part of my daily work, I would make sure to
>>>> use an editing tool that can syntax-highlight FOOBAR source code.
>>>> That would be my "best practices" suggestion. Now, if people choose
>>>> not to follow my "best practices" suggestion, that is their right.
>>>>
>>>>
>>>>> and often the HTML-specific ones will not allow you to color <...>
>>>>> differently from <#...>. Some potential users might have trouble
>>>>> choosing colors for their MSN... your blithe hand-waving about
>>>>> proper use of syntax highlighting will get you glazed eyeballs at
>>>>> best.
>>>>>
>>>>> Also what of this:
>>>>>
>>>>> <td <#if item.imagetype = "big">colspan="2"</#if>>
>>>>> <span style="font-family:Helvetica,sans-serif;
>>>>> <#if item.sale = "limited">color:#cc9933;
>>>>> <#elseif item.sale = "new">color:#eeff00;</#if>">
>>>>> <#if item.selected><b <#if
>>>>> item.current>style="font-size:1.0em;"</#if>></#if>
>>>>> ${item.name}<#if item.selected></b></#if>
>>>>> </span>
>>>>>
>>>>> How exactly is this going to look with syntax highlighting, given
>>>>> that HTML and FTL are nested within each other, and-- nested within
>>>>> quoting, which vexes even the best editors...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I'll concede you do have a point. I copy-pasted the above fragment
>>>> into what is doubtless one of the very best editors, JEdit
>>>> (http://www.jedit.org) which has syntax-highlighting for FreeMarker
>>>> out-of-the-box.
>>>>
>>>> It fails to syntax highlight everything in the above mish-mash
>>>> correctly.
>>>>
>>>> Still, the fact is that the above code fragment is hardly
>>>> recommendable. If somebody sent this in as an example of what they
>>>> were doing on the freemarker-user mailing list, I do not think that
>>>> I could refrain from offering some stylistic advice.
>>>>
>>>> Actually, here is one way of refactoring your code fragment so that
>>>> it is more readable and maintainable.
>>>>
>>>> <#if item.imagetype="big">
>>>> <#assign colspan="2">
>>>> <#else>
>>>> <#assign colspan="1">
>>>> </#if>
>>>>
>>>> <#assign style>
>>>> font-family:Helvetica,sans-serif;
>>>> <#if item.sale = "limited">color:#cc9933;
>>>> <#elseif item.sale = "new">color:#eeff00;</#if>"
>>>> </#assign>
>>>>
>>>> <#macro showItem item>
>>>> <#local style="">
>>>> <#if item.current>
>>>> <#local style='style="font-size:1.0em;"'>
>>>> </#if>
>>>> <#if item.selected><b ${style}></#if>
>>>> ${item.name}
>>>> <#if item.selected></b></#if>
>>>> </#macro>
>>>>
>>>>
>>>> <#--
>>>> Now, having set up the above helpers, here is the templatized
>>>> HTML we output. This is really much better style.
>>>> -->
>>>>
>>>> <td colspan="${colspan}">
>>>> <span style="${style}">
>>>> <@showItem item />
>>>> </span>
>>>>
>>>>
>>>> Perhaps needless to say, jEdit has no problem syntax highlighting
>>>> the above refactored version. So, my tentative conclusion from this
>>>> is that you can write FreeMarker template code that confuses the
>>>> syntax highlighting rules in JEdit, say. Also, such code is
>>>> obfuscated for a human reading it.
>>>>
>>>> OTOH, such code should be refactored generally.
>>>>
>>>>
>>>>>
>>>>> Also note the $ which usually indicates to the user, a variable, is
>>>>> missing from inside the directives, which makes the directives
>>>>> "disappear" even more.
>>>>> Finally note that the need to both open and close each opening and
>>>>> closing directive with the same opening and closing delimiters used
>>>>> by HTML is really fricking confusing, and downright annoying to
>>>>> have to type!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I would discourage people from writing templates that look like the
>>>> example you provided. Consider my refactored version.
>>>>
>>>>>
>>>>> I don't really like having to type < and >. I think the choice to
>>>>> allow [ and ] is a good one. But I much prefer this, due to the
>>>>> other reasons listed above:
>>>>>
>>>>> <td #if( $item.ImageType == "big" )colspan="2"#end>
>>>>> <span style="font-family:Helvetica,sans-serif;
>>>>> #if( $item.Sale == 'limited' )color:#cc9933;
>>>>> #elseif( $item.Sale == 'new' )color:#eeff00;#end">
>>>>> #if( $item.Selected )<b #if( $item.Current
>>>>> )style="font-size:1.0em;"#end>#end
>>>>> ${item.Name}#if( $item.Selected )</b>#end
>>>>> </span>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Well, okay, it might be a bit better, Jason. Frankly, it still looks
>>>> like hell. I think, that if somebody offered up this as an example
>>>> of their Velocity usage, one really ought to suggest similar
>>>> refactorings along the lines of what I did above, to make it more
>>>> readable and maintainable.
>>>>
>>>> Well, on second thought, I suppose that a lot of existing code out
>>>> there probably does look like this. (Or worse.) I often am stunned
>>>> when people send in code fragments of what they're doing -- Java or
>>>> FreeMarker or something else. It is not exactly clear what I can do
>>>> about this. People will always be able to write muddled obfuscated
>>>> code that is hard to read or maintain in any language.
>>>>
>>>> Anyway, as I pointed out in another response to Chad, we simply have
>>>> no evidence that people confusing FreeMarker instructions with HTML
>>>> tags is a real-world problem out there.
>>>>
>>>> Jonathan Revusky
>>>> --
>>>> lead developer, FreeMarker project, http://freemarker.org/
>>>>
>>>>>
>>>>> --jason
>>>>>
>>>>> Jonathan Revusky wrote:
>>>>>
>>>>>> Chad Meadows wrote:
>>>>>>
>>>>>>> The analogy is not accurate.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Okay, analogies, by their nature are not "accurate". "Life is like
>>>>>> a box of chocolates..." and so on. My point was really just that
>>>>>> it is surprising that someone who primarily knows HTML or XML
>>>>>> would find FreeMarker's pseudo-tag approach unpalatable. The basic
>>>>>> *approach* of a FreeMarker if statement, say, is familiar to such
>>>>>> a person:
>>>>>>
>>>>>> <#if user.isLoggedIn>
>>>>>> ...
>>>>>> </#if>
>>>>>>
>>>>>> After all, it's an approach that they are used to, bounding things
>>>>>> with <foo>...</foo>. And this could make for more initial comfort
>>>>>> level than another, completely unfamiliar syntax.
>>>>>>
>>>>>> And this is the same mechanism that makes Java initially more
>>>>>> palatable to a C hacker than Smalltalk, say. That was my point.
>>>>>>
>>>>>>> If Java was written by interweaving it within a C program this
>>>>>>> would be an accurate analogy. In which case, I would suspect
>>>>>>> everyone would then consider that a syntax nightmare.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Well, okay, this is stretching the analogy further than I would
>>>>>> have intended. It's all apples and oranges. Java is note a
>>>>>> templating language. But fine, mea culpa, the analogy is obviously
>>>>>> quite imperfect.
>>>>>>
>>>>>> So, let's not work that analogy further. Let me take another tack
>>>>>> on this topic....
>>>>>>
>>>>>> Okay? Here goes....
>>>>>>
>>>>>> Chad, this whole idea being bandied about, that people working on
>>>>>> FreeMarker page templates have a problem distinguishing the
>>>>>> FreeMarker directives from the HTML tags is, to the best of my
>>>>>> knowledge, a complete and utter non-issue.
>>>>>>
>>>>>> I just realized that I have now been involved with FreeMarker for
>>>>>> 6 years, first simply as a user (which is the period in which I
>>>>>> actually interacted most with designers who were using FM
>>>>>> templates) and then later as a developer, and eventually, as
>>>>>> project lead, rewriting the parser/renderer core of the engine for
>>>>>> the 2.x releases.
>>>>>>
>>>>>> In all of that time, I have never heard somebody who actually uses
>>>>>> FreeMarker complain that they confuse the FreeMarker instructions
>>>>>> with HTML tags -- that this is a problem. I believe you could
>>>>>> google on our mailing list archives and the list archives of high
>>>>>> profile projects that use FreeMarker as a view (like OfBiz and
>>>>>> now, Webwork) and you will simply not see anybody complaining
>>>>>> about this. (They may have other FreeMarker-related issues, sure,
>>>>>> but not this one.)
>>>>>>
>>>>>> I grant now, that this is not 100% absolute proof that this is not
>>>>>> a real-world problem. However, I can only go by what evidence I
>>>>>> have. Don't you think that, if this really were a widespread
>>>>>> problem, that, in 6 years, it would have come to my attention?
>>>>>>
>>>>>> Now, what is interesting is that, people have lobbied for an
>>>>>> alternative syntax that didn't delimit with <...>. And the latest
>>>>>> version in CVS (and soon to be released) allows [#...] as an
>>>>>> alternative to <#....>.
>>>>>>
>>>>>> BUT if you look at the messages where people lobbied for this,
>>>>>> there was never any mention of human template writers being
>>>>>> confused by the syntax. It was entirely to make the templates
>>>>>> compatible with certain tools -- for example, HTML-oriented
>>>>>> editing tools that got confused by pseudo-tags.
>>>>>>
>>>>>> IOW, the syntactical issue has come up, but it was always because
>>>>>> the syntax confused certain tools -- never, to my recollection
>>>>>> that it confused people. I reason that if that had been an issue,
>>>>>> this would have also come out in such conversations. It never did.
>>>>>>
>>>>>> But, you don't really have to take my word for this, Chad. Nor
>>>>>> should you -- at least, if this still is a major concern of yours
>>>>>> wrt FreeMarker. If you are at IBM and have web page designers on
>>>>>> staff, see if you can have one or more of them work with
>>>>>> FreeMarker on a pilot project for a certain period of time and see
>>>>>> whether there really is a problem of people confusing FreeMarker
>>>>>> directives with HTML or XML tags.
>>>>>>
>>>>>> I will re-iterate that FreeMarker tags all start with quite
>>>>>> distinctive character sequences:
>>>>>>
>>>>>> <#
>>>>>>
>>>>>> and
>>>>>>
>>>>>> <@
>>>>>>
>>>>>> that are not valid XML/HTML anyway. These patterns can be syntax
>>>>>> highlighted in a separate color. (And of course, they should be.)
>>>>>>
>>>>>> Now, if there is real solid evidence that this is a genuine
>>>>>> problem, that people still get all dazed and confused because they
>>>>>> can't distinguish a FM directive from an HTML tag, like *even* if
>>>>>> you syntax-highlight HTML tags in orange and FTL in purple, I will
>>>>>> be very interested in hearing about this.
>>>>>>
>>>>>> But, really, you must understand that, until then, given the data
>>>>>> that I have on this question, it just does not seem like a
>>>>>> fruitful line of inquiry or discussion. It seems utterly sterile
>>>>>> because it simply does not appear that this is a real-world problem.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Jonathan Revusky
>>>>>> --
>>>>>> lead developer, FreeMarker project, http://freemarker.org/
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Chad.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Austin Taylor <au...@gmail.com> 10/08/2005 05:14 PM
>>>>>>> Please respond to
>>>>>>> "Velocity Users List"
>>>>>>>
>>>>>>>
>>>>>>> To
>>>>>>> Velocity Users List <ve...@jakarta.apache.org>
>>>>>>> cc
>>>>>>>
>>>>>>> Subject
>>>>>>> Re: [ANN] Viento - WHY?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Jonathan, you really are coming across as polemic. Try to be more
>>>>>>> contemplative (like maybe you actually considered the other
>>>>>>> person's point
>>>>>>> of view) than defensive.
>>>>>>>
>>>>>>> Well, in other contexts, such things have been deemed to be an
>>>>>>>
>>>>>>>> advantage. Java syntax was based on that of C to make it more
>>>>>>>> palatable
>>>>>>>> to all the existing C hackers. Java, in fact, looks like C but
>>>>>>>> is not C.
>>>>>>>>
>>>>>>>> Most people would guess that this strategy did work, in fact.
>>>>>>>> So, why is
>>>>>>>> this case so different? If FTL looks like HTML but is not HTML,
>>>>>>>> why does
>>>>>>>> this lead HTML hackers to reject it, yet when Java looks like C
>>>>>>>> but is
>>>>>>>> not C this would tend to enhance Java's acceptability?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> That's a very interesting point. I suppose, for HTML people,
>>>>>>> FreeMarker's
>>>>>>> syntax might be great. As a programmer, I prefer something that
>>>>>>> feels more
>>>>>>> like a 'real' programming language. The syntax in Viento is
>>>>>>> designed to be
>>>>>>> like Java, with a little sugar from Ruby to make it worthwhile,
>>>>>>> and a few $
>>>>>>> from perl to make it a template language.
>>>>>>>
>>>>>>> Austin
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>>>>>> For additional commands, e-mail:
>>>>>> velocity-user-help@jakarta.apache.org
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Jason Pettiss <ja...@TheCatalis.com>.
I have no disagreements with what you say. It isn't that content
authors can't think-- it's that they don't think like programmers. For
example, I have tried to show mine the merits of abstraction,
encapsulation, generic utility... they just nod, disinterested. They
have no need for it... for them the interesting challenge is not how to
efficiently represent content, and as they type it out, their idle
cycles aren't spent on modularizing, instead, they're thinking about
colors, flow, layout. I'm not opposed to functionality. I just didn't
need it for my purposes.
And yes, taking the electric blue 486 over the boring looking 3 Ghz
monster would be missing the point of the computer, but people do this.
Some people will specifically not buy a car based on the lack of
cupholders. Put a little green food coloring into your delicious batch
of chocolate chip cookies and people won't be so eager to steal them
when you're not looking.
You gotta have the secondary aesthetics, at least for the adoption
phase. The nice Mazda feature which makes the AC vents oscillate back
and forth sold a lot of people-- even though they ended up turning it
off after the first week, because it got annoying... purchasing
decisions are almost always based on "feel-good" trivialities rather
than strictly rational evaluation...
Jonathan Revusky wrote:
> Jason Pettiss wrote:
>
>> Hey, I agree with you. With a little more thinking, a little more
>> up-front typing, you can make things readable and at the same time
>> more concise. And inherently *better*. (Btw, the #assign feature is
>> supercool.)
>>
>> Have you see the HTML written by content authors that aren't
>> developers? Or worse-- what they produce when using the "aid" of a
>> wysiwyg editor? They're not going to do all that super-nice stuff
>> you used there-- because it doesn't appear "right" in their
>> super-nifty editor... in fact until you add a framework to the
>> template language which mock-evaluates the template in the wysiwyg
>> editor, these extra features will just go to waste...
>
>
> Here, you're bringing up a real issue, but it is not specific to
> FreeMarker. It's specific to any broadly similar templating tool.
>
> But also, there is an undercurrent in the above comments of yours that
> I object to -- basically, one infers this idea that people who
> primarily work with HTML, on the presentation layer, are dummies.
> Something like:
>
> "Oh, that's a good feature you can use to encapsulate and clean up
> your template code, but those people are too dumb to use it anyway."
>
> This kind of attitude makes me uncomfortable. Maybe it actually
> overlaps with other kinds of things that I find troubling. How would
> you react to something like:
>
> "No point spending money on a cultural center in a working class
> neighborhood. Joe Six-Pack has no use for that kind of stuff anyway."
>
> I would object strenuously to the above kind of argument.
>
> But getting back to actual web development, I would be wary of
> fostering an attitude that is contemptuous of the abilities of other
> people on the team. It is probably quite true that front-end people
> would not initially structure their pages very well, but that is
> simply because they lack experience and nobody has got them started on
> the right path to doing that.
>
> Anyway, as somebody deeply involved in developing this kind of tool,
> all I can really do is provide the feature set that I think is
> necessary. Some people will use the tool more effectively than other
> people, no question.
>
>
>>
>> And until then, they'll just bitch and moan about the "extra" < / >
>> all over the place.
>
>
> Well, people keep making claims like this, but that doesn't make it
> true. The fact of the matter is that people who use FreeMarker to do
> serious work are simply accustomed to the syntax and do not expend
> energy moaning about what characters they have to type.
>
> Similarly, people who write code in Pascal-ish languages where blocks
> are delimited by an explicit 'begin' and 'end' (unlike the { and } in
> C-ish languages) do not spend their days moaning about having to type
> begin and end. (Besides, you have heard of keystroke macros, right?)
>
> Finally, any such tool has to have some syntax or other. As a
> practical matter, within reasonable bounds, people just get used to
> whatever it is. Fairly quickly, probably, a few days at most.
>
>> And in most cases they're unnecessary anyway-- so why should I have
>> to type them? You say that's a shallow question, but some languages
>> do measure power by the savings of an extra character of syntax here
>> and there, even at the expense of readability.
>
>
> Look, consider what you're saying for a second, you might step back
> from it and consider: "Does this really make sense?"
>
> You can compare two things on aesthetic grounds, like one is prettier
> than the other, when the two things are basically comparable
> functionally. The Casio watch on my wrist, I would say that I bought
> it solely because I liked how it looked. Why? Because any watch I
> bought would keep the time accurately and reliably, so my choice would
> just come down to style and aesthetics. And this may be the case with
> something in a very mature product category, where anything you opt
> for is basically very good on a purely *functional* level.
>
> However, if somebody offers you a new 3 Ghz Pentium 4 to put on your
> desk that is an ugly shade of beige, and gives you as an alternative,
> an old 486 that is a really nice electric blue color, you cannot
> really opt for the 486.
>
> To base your decision on 2nd order aesthetic concerns can really only
> make sense when the things you are comparing are broadly comparable
> *functionally*.
>
> If you go look at blog entries where people talk about switching from
> Velocity to FM, you see the people talking about functionality that
> they are getting -- JSP taglib support, i18n support, a macro system
> that's done properly -- and so on. One blog I know of, where a guy
> stated a strong preference for Velocity, it was entirely because he
> just likes the syntax better. (Or, one infers, it's the first one he
> used, and he got used to the syntax...)
>
> http://weblog.flop.ca/2005/03/27/1111947748000.html
>
> But really, isn't it only reasonable to base your decision on
> aesthetics if the things you're choosing between are comparable
> *functionally*? Anything else is putting the cart before the horse.
>
> Jonathan Revusky
> --
> FreeMarker project, http://freemarker.org/
>
>
>
>
>
>> I just don't see why I should have to stroke the parser's ego with
>> these extra characters, when it detracts from readability and isn't
>> strictly necessary. I don't really care about having one right way
>> as much as having the way that suits my needs at the present moment.
>>
>> --jason
>>
>> Jonathan Revusky wrote:
>>
>>> Jason Pettiss wrote:
>>>
>>>> Syntax highlighting isn't very flexible in many popular editors,
>>>
>>>
>>>
>>>
>>> I haven't done a survey of this issue. Which editors are you
>>> referring to specifically?
>>>
>>> Though, my honest reaction is that, I, personally, if I were writing
>>> in language FOOBAR as part of my daily work, I would make sure to
>>> use an editing tool that can syntax-highlight FOOBAR source code.
>>> That would be my "best practices" suggestion. Now, if people choose
>>> not to follow my "best practices" suggestion, that is their right.
>>>
>>>
>>>> and often the HTML-specific ones will not allow you to color <...>
>>>> differently from <#...>. Some potential users might have trouble
>>>> choosing colors for their MSN... your blithe hand-waving about
>>>> proper use of syntax highlighting will get you glazed eyeballs at
>>>> best.
>>>>
>>>> Also what of this:
>>>>
>>>> <td <#if item.imagetype = "big">colspan="2"</#if>>
>>>> <span style="font-family:Helvetica,sans-serif;
>>>> <#if item.sale = "limited">color:#cc9933;
>>>> <#elseif item.sale = "new">color:#eeff00;</#if>">
>>>> <#if item.selected><b <#if
>>>> item.current>style="font-size:1.0em;"</#if>></#if>
>>>> ${item.name}<#if item.selected></b></#if>
>>>> </span>
>>>>
>>>> How exactly is this going to look with syntax highlighting, given
>>>> that HTML and FTL are nested within each other, and-- nested within
>>>> quoting, which vexes even the best editors...
>>>
>>>
>>>
>>>
>>> I'll concede you do have a point. I copy-pasted the above fragment
>>> into what is doubtless one of the very best editors, JEdit
>>> (http://www.jedit.org) which has syntax-highlighting for FreeMarker
>>> out-of-the-box.
>>>
>>> It fails to syntax highlight everything in the above mish-mash
>>> correctly.
>>>
>>> Still, the fact is that the above code fragment is hardly
>>> recommendable. If somebody sent this in as an example of what they
>>> were doing on the freemarker-user mailing list, I do not think that
>>> I could refrain from offering some stylistic advice.
>>>
>>> Actually, here is one way of refactoring your code fragment so that
>>> it is more readable and maintainable.
>>>
>>> <#if item.imagetype="big">
>>> <#assign colspan="2">
>>> <#else>
>>> <#assign colspan="1">
>>> </#if>
>>>
>>> <#assign style>
>>> font-family:Helvetica,sans-serif;
>>> <#if item.sale = "limited">color:#cc9933;
>>> <#elseif item.sale = "new">color:#eeff00;</#if>"
>>> </#assign>
>>>
>>> <#macro showItem item>
>>> <#local style="">
>>> <#if item.current>
>>> <#local style='style="font-size:1.0em;"'>
>>> </#if>
>>> <#if item.selected><b ${style}></#if>
>>> ${item.name}
>>> <#if item.selected></b></#if>
>>> </#macro>
>>>
>>>
>>> <#--
>>> Now, having set up the above helpers, here is the templatized
>>> HTML we output. This is really much better style.
>>> -->
>>>
>>> <td colspan="${colspan}">
>>> <span style="${style}">
>>> <@showItem item />
>>> </span>
>>>
>>>
>>> Perhaps needless to say, jEdit has no problem syntax highlighting
>>> the above refactored version. So, my tentative conclusion from this
>>> is that you can write FreeMarker template code that confuses the
>>> syntax highlighting rules in JEdit, say. Also, such code is
>>> obfuscated for a human reading it.
>>>
>>> OTOH, such code should be refactored generally.
>>>
>>>
>>>>
>>>> Also note the $ which usually indicates to the user, a variable, is
>>>> missing from inside the directives, which makes the directives
>>>> "disappear" even more.
>>>> Finally note that the need to both open and close each opening and
>>>> closing directive with the same opening and closing delimiters used
>>>> by HTML is really fricking confusing, and downright annoying to
>>>> have to type!
>>>
>>>
>>>
>>>
>>> I would discourage people from writing templates that look like the
>>> example you provided. Consider my refactored version.
>>>
>>>>
>>>> I don't really like having to type < and >. I think the choice to
>>>> allow [ and ] is a good one. But I much prefer this, due to the
>>>> other reasons listed above:
>>>>
>>>> <td #if( $item.ImageType == "big" )colspan="2"#end>
>>>> <span style="font-family:Helvetica,sans-serif;
>>>> #if( $item.Sale == 'limited' )color:#cc9933;
>>>> #elseif( $item.Sale == 'new' )color:#eeff00;#end">
>>>> #if( $item.Selected )<b #if( $item.Current
>>>> )style="font-size:1.0em;"#end>#end
>>>> ${item.Name}#if( $item.Selected )</b>#end
>>>> </span>
>>>
>>>
>>>
>>>
>>> Well, okay, it might be a bit better, Jason. Frankly, it still looks
>>> like hell. I think, that if somebody offered up this as an example
>>> of their Velocity usage, one really ought to suggest similar
>>> refactorings along the lines of what I did above, to make it more
>>> readable and maintainable.
>>>
>>> Well, on second thought, I suppose that a lot of existing code out
>>> there probably does look like this. (Or worse.) I often am stunned
>>> when people send in code fragments of what they're doing -- Java or
>>> FreeMarker or something else. It is not exactly clear what I can do
>>> about this. People will always be able to write muddled obfuscated
>>> code that is hard to read or maintain in any language.
>>>
>>> Anyway, as I pointed out in another response to Chad, we simply have
>>> no evidence that people confusing FreeMarker instructions with HTML
>>> tags is a real-world problem out there.
>>>
>>> Jonathan Revusky
>>> --
>>> lead developer, FreeMarker project, http://freemarker.org/
>>>
>>>>
>>>> --jason
>>>>
>>>> Jonathan Revusky wrote:
>>>>
>>>>> Chad Meadows wrote:
>>>>>
>>>>>> The analogy is not accurate.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Okay, analogies, by their nature are not "accurate". "Life is like
>>>>> a box of chocolates..." and so on. My point was really just that
>>>>> it is surprising that someone who primarily knows HTML or XML
>>>>> would find FreeMarker's pseudo-tag approach unpalatable. The basic
>>>>> *approach* of a FreeMarker if statement, say, is familiar to such
>>>>> a person:
>>>>>
>>>>> <#if user.isLoggedIn>
>>>>> ...
>>>>> </#if>
>>>>>
>>>>> After all, it's an approach that they are used to, bounding things
>>>>> with <foo>...</foo>. And this could make for more initial comfort
>>>>> level than another, completely unfamiliar syntax.
>>>>>
>>>>> And this is the same mechanism that makes Java initially more
>>>>> palatable to a C hacker than Smalltalk, say. That was my point.
>>>>>
>>>>>> If Java was written by interweaving it within a C program this
>>>>>> would be an accurate analogy. In which case, I would suspect
>>>>>> everyone would then consider that a syntax nightmare.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Well, okay, this is stretching the analogy further than I would
>>>>> have intended. It's all apples and oranges. Java is note a
>>>>> templating language. But fine, mea culpa, the analogy is obviously
>>>>> quite imperfect.
>>>>>
>>>>> So, let's not work that analogy further. Let me take another tack
>>>>> on this topic....
>>>>>
>>>>> Okay? Here goes....
>>>>>
>>>>> Chad, this whole idea being bandied about, that people working on
>>>>> FreeMarker page templates have a problem distinguishing the
>>>>> FreeMarker directives from the HTML tags is, to the best of my
>>>>> knowledge, a complete and utter non-issue.
>>>>>
>>>>> I just realized that I have now been involved with FreeMarker for
>>>>> 6 years, first simply as a user (which is the period in which I
>>>>> actually interacted most with designers who were using FM
>>>>> templates) and then later as a developer, and eventually, as
>>>>> project lead, rewriting the parser/renderer core of the engine for
>>>>> the 2.x releases.
>>>>>
>>>>> In all of that time, I have never heard somebody who actually uses
>>>>> FreeMarker complain that they confuse the FreeMarker instructions
>>>>> with HTML tags -- that this is a problem. I believe you could
>>>>> google on our mailing list archives and the list archives of high
>>>>> profile projects that use FreeMarker as a view (like OfBiz and
>>>>> now, Webwork) and you will simply not see anybody complaining
>>>>> about this. (They may have other FreeMarker-related issues, sure,
>>>>> but not this one.)
>>>>>
>>>>> I grant now, that this is not 100% absolute proof that this is not
>>>>> a real-world problem. However, I can only go by what evidence I
>>>>> have. Don't you think that, if this really were a widespread
>>>>> problem, that, in 6 years, it would have come to my attention?
>>>>>
>>>>> Now, what is interesting is that, people have lobbied for an
>>>>> alternative syntax that didn't delimit with <...>. And the latest
>>>>> version in CVS (and soon to be released) allows [#...] as an
>>>>> alternative to <#....>.
>>>>>
>>>>> BUT if you look at the messages where people lobbied for this,
>>>>> there was never any mention of human template writers being
>>>>> confused by the syntax. It was entirely to make the templates
>>>>> compatible with certain tools -- for example, HTML-oriented
>>>>> editing tools that got confused by pseudo-tags.
>>>>>
>>>>> IOW, the syntactical issue has come up, but it was always because
>>>>> the syntax confused certain tools -- never, to my recollection
>>>>> that it confused people. I reason that if that had been an issue,
>>>>> this would have also come out in such conversations. It never did.
>>>>>
>>>>> But, you don't really have to take my word for this, Chad. Nor
>>>>> should you -- at least, if this still is a major concern of yours
>>>>> wrt FreeMarker. If you are at IBM and have web page designers on
>>>>> staff, see if you can have one or more of them work with
>>>>> FreeMarker on a pilot project for a certain period of time and see
>>>>> whether there really is a problem of people confusing FreeMarker
>>>>> directives with HTML or XML tags.
>>>>>
>>>>> I will re-iterate that FreeMarker tags all start with quite
>>>>> distinctive character sequences:
>>>>>
>>>>> <#
>>>>>
>>>>> and
>>>>>
>>>>> <@
>>>>>
>>>>> that are not valid XML/HTML anyway. These patterns can be syntax
>>>>> highlighted in a separate color. (And of course, they should be.)
>>>>>
>>>>> Now, if there is real solid evidence that this is a genuine
>>>>> problem, that people still get all dazed and confused because they
>>>>> can't distinguish a FM directive from an HTML tag, like *even* if
>>>>> you syntax-highlight HTML tags in orange and FTL in purple, I will
>>>>> be very interested in hearing about this.
>>>>>
>>>>> But, really, you must understand that, until then, given the data
>>>>> that I have on this question, it just does not seem like a
>>>>> fruitful line of inquiry or discussion. It seems utterly sterile
>>>>> because it simply does not appear that this is a real-world problem.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Jonathan Revusky
>>>>> --
>>>>> lead developer, FreeMarker project, http://freemarker.org/
>>>>>
>>>>>
>>>>>>
>>>>>> Chad.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Austin Taylor <au...@gmail.com> 10/08/2005 05:14 PM
>>>>>> Please respond to
>>>>>> "Velocity Users List"
>>>>>>
>>>>>>
>>>>>> To
>>>>>> Velocity Users List <ve...@jakarta.apache.org>
>>>>>> cc
>>>>>>
>>>>>> Subject
>>>>>> Re: [ANN] Viento - WHY?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jonathan, you really are coming across as polemic. Try to be more
>>>>>> contemplative (like maybe you actually considered the other
>>>>>> person's point
>>>>>> of view) than defensive.
>>>>>>
>>>>>> Well, in other contexts, such things have been deemed to be an
>>>>>>
>>>>>>> advantage. Java syntax was based on that of C to make it more
>>>>>>> palatable
>>>>>>> to all the existing C hackers. Java, in fact, looks like C but
>>>>>>> is not C.
>>>>>>>
>>>>>>> Most people would guess that this strategy did work, in fact.
>>>>>>> So, why is
>>>>>>> this case so different? If FTL looks like HTML but is not HTML,
>>>>>>> why does
>>>>>>> this lead HTML hackers to reject it, yet when Java looks like C
>>>>>>> but is
>>>>>>> not C this would tend to enhance Java's acceptability?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> That's a very interesting point. I suppose, for HTML people,
>>>>>> FreeMarker's
>>>>>> syntax might be great. As a programmer, I prefer something that
>>>>>> feels more
>>>>>> like a 'real' programming language. The syntax in Viento is
>>>>>> designed to be
>>>>>> like Java, with a little sugar from Ruby to make it worthwhile,
>>>>>> and a few $
>>>>>> from perl to make it a template language.
>>>>>>
>>>>>> Austin
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail:
>>>>> velocity-user-help@jakarta.apache.org
>>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Jason Pettiss wrote:
> Hey, I agree with you. With a little more thinking, a little more
> up-front typing, you can make things readable and at the same time more
> concise. And inherently *better*. (Btw, the #assign feature is
> supercool.)
>
> Have you see the HTML written by content authors that aren't
> developers? Or worse-- what they produce when using the "aid" of a
> wysiwyg editor? They're not going to do all that super-nice stuff you
> used there-- because it doesn't appear "right" in their super-nifty
> editor... in fact until you add a framework to the template language
> which mock-evaluates the template in the wysiwyg editor, these extra
> features will just go to waste...
Here, you're bringing up a real issue, but it is not specific to
FreeMarker. It's specific to any broadly similar templating tool.
But also, there is an undercurrent in the above comments of yours that I
object to -- basically, one infers this idea that people who primarily
work with HTML, on the presentation layer, are dummies. Something like:
"Oh, that's a good feature you can use to encapsulate and clean up your
template code, but those people are too dumb to use it anyway."
This kind of attitude makes me uncomfortable. Maybe it actually overlaps
with other kinds of things that I find troubling. How would you react to
something like:
"No point spending money on a cultural center in a working class
neighborhood. Joe Six-Pack has no use for that kind of stuff anyway."
I would object strenuously to the above kind of argument.
But getting back to actual web development, I would be wary of fostering
an attitude that is contemptuous of the abilities of other people on the
team. It is probably quite true that front-end people would not
initially structure their pages very well, but that is simply because
they lack experience and nobody has got them started on the right path
to doing that.
Anyway, as somebody deeply involved in developing this kind of tool, all
I can really do is provide the feature set that I think is necessary.
Some people will use the tool more effectively than other people, no
question.
>
> And until then, they'll just bitch and moan about the "extra" < / > all
> over the place.
Well, people keep making claims like this, but that doesn't make it
true. The fact of the matter is that people who use FreeMarker to do
serious work are simply accustomed to the syntax and do not expend
energy moaning about what characters they have to type.
Similarly, people who write code in Pascal-ish languages where blocks
are delimited by an explicit 'begin' and 'end' (unlike the { and } in
C-ish languages) do not spend their days moaning about having to type
begin and end. (Besides, you have heard of keystroke macros, right?)
Finally, any such tool has to have some syntax or other. As a practical
matter, within reasonable bounds, people just get used to whatever it
is. Fairly quickly, probably, a few days at most.
> And in most cases they're unnecessary anyway-- so why
> should I have to type them? You say that's a shallow question, but some
> languages do measure power by the savings of an extra character of
> syntax here and there, even at the expense of readability.
Look, consider what you're saying for a second, you might step back from
it and consider: "Does this really make sense?"
You can compare two things on aesthetic grounds, like one is prettier
than the other, when the two things are basically comparable
functionally. The Casio watch on my wrist, I would say that I bought it
solely because I liked how it looked. Why? Because any watch I bought
would keep the time accurately and reliably, so my choice would just
come down to style and aesthetics. And this may be the case with
something in a very mature product category, where anything you opt for
is basically very good on a purely *functional* level.
However, if somebody offers you a new 3 Ghz Pentium 4 to put on your
desk that is an ugly shade of beige, and gives you as an alternative, an
old 486 that is a really nice electric blue color, you cannot really opt
for the 486.
To base your decision on 2nd order aesthetic concerns can really only
make sense when the things you are comparing are broadly comparable
*functionally*.
If you go look at blog entries where people talk about switching from
Velocity to FM, you see the people talking about functionality that they
are getting -- JSP taglib support, i18n support, a macro system that's
done properly -- and so on. One blog I know of, where a guy stated a
strong preference for Velocity, it was entirely because he just likes
the syntax better. (Or, one infers, it's the first one he used, and he
got used to the syntax...)
http://weblog.flop.ca/2005/03/27/1111947748000.html
But really, isn't it only reasonable to base your decision on aesthetics
if the things you're choosing between are comparable *functionally*?
Anything else is putting the cart before the horse.
Jonathan Revusky
--
FreeMarker project, http://freemarker.org/
> I just don't see why I should have to stroke the parser's ego with these
> extra characters, when it detracts from readability and isn't strictly
> necessary. I don't really care about having one right way as much as
> having the way that suits my needs at the present moment.
>
> --jason
>
> Jonathan Revusky wrote:
>
>> Jason Pettiss wrote:
>>
>>> Syntax highlighting isn't very flexible in many popular editors,
>>
>>
>>
>> I haven't done a survey of this issue. Which editors are you referring
>> to specifically?
>>
>> Though, my honest reaction is that, I, personally, if I were writing
>> in language FOOBAR as part of my daily work, I would make sure to use
>> an editing tool that can syntax-highlight FOOBAR source code. That
>> would be my "best practices" suggestion. Now, if people choose not to
>> follow my "best practices" suggestion, that is their right.
>>
>>
>>> and often the HTML-specific ones will not allow you to color <...>
>>> differently from <#...>. Some potential users might have trouble
>>> choosing colors for their MSN... your blithe hand-waving about proper
>>> use of syntax highlighting will get you glazed eyeballs at best.
>>>
>>> Also what of this:
>>>
>>> <td <#if item.imagetype = "big">colspan="2"</#if>>
>>> <span style="font-family:Helvetica,sans-serif;
>>> <#if item.sale = "limited">color:#cc9933;
>>> <#elseif item.sale = "new">color:#eeff00;</#if>">
>>> <#if item.selected><b <#if
>>> item.current>style="font-size:1.0em;"</#if>></#if>
>>> ${item.name}<#if item.selected></b></#if>
>>> </span>
>>>
>>> How exactly is this going to look with syntax highlighting, given
>>> that HTML and FTL are nested within each other, and-- nested within
>>> quoting, which vexes even the best editors...
>>
>>
>>
>> I'll concede you do have a point. I copy-pasted the above fragment
>> into what is doubtless one of the very best editors, JEdit
>> (http://www.jedit.org) which has syntax-highlighting for FreeMarker
>> out-of-the-box.
>>
>> It fails to syntax highlight everything in the above mish-mash correctly.
>>
>> Still, the fact is that the above code fragment is hardly
>> recommendable. If somebody sent this in as an example of what they
>> were doing on the freemarker-user mailing list, I do not think that I
>> could refrain from offering some stylistic advice.
>>
>> Actually, here is one way of refactoring your code fragment so that it
>> is more readable and maintainable.
>>
>> <#if item.imagetype="big">
>> <#assign colspan="2">
>> <#else>
>> <#assign colspan="1">
>> </#if>
>>
>> <#assign style>
>> font-family:Helvetica,sans-serif;
>> <#if item.sale = "limited">color:#cc9933;
>> <#elseif item.sale = "new">color:#eeff00;</#if>"
>> </#assign>
>>
>> <#macro showItem item>
>> <#local style="">
>> <#if item.current>
>> <#local style='style="font-size:1.0em;"'>
>> </#if>
>> <#if item.selected><b ${style}></#if>
>> ${item.name}
>> <#if item.selected></b></#if>
>> </#macro>
>>
>>
>> <#--
>> Now, having set up the above helpers, here is the templatized
>> HTML we output. This is really much better style.
>> -->
>>
>> <td colspan="${colspan}">
>> <span style="${style}">
>> <@showItem item />
>> </span>
>>
>>
>> Perhaps needless to say, jEdit has no problem syntax highlighting the
>> above refactored version. So, my tentative conclusion from this is
>> that you can write FreeMarker template code that confuses the syntax
>> highlighting rules in JEdit, say. Also, such code is obfuscated for a
>> human reading it.
>>
>> OTOH, such code should be refactored generally.
>>
>>
>>>
>>> Also note the $ which usually indicates to the user, a variable, is
>>> missing from inside the directives, which makes the directives
>>> "disappear" even more.
>>> Finally note that the need to both open and close each opening and
>>> closing directive with the same opening and closing delimiters used
>>> by HTML is really fricking confusing, and downright annoying to have
>>> to type!
>>
>>
>>
>> I would discourage people from writing templates that look like the
>> example you provided. Consider my refactored version.
>>
>>>
>>> I don't really like having to type < and >. I think the choice to
>>> allow [ and ] is a good one. But I much prefer this, due to the
>>> other reasons listed above:
>>>
>>> <td #if( $item.ImageType == "big" )colspan="2"#end>
>>> <span style="font-family:Helvetica,sans-serif;
>>> #if( $item.Sale == 'limited' )color:#cc9933;
>>> #elseif( $item.Sale == 'new' )color:#eeff00;#end">
>>> #if( $item.Selected )<b #if( $item.Current
>>> )style="font-size:1.0em;"#end>#end
>>> ${item.Name}#if( $item.Selected )</b>#end
>>> </span>
>>
>>
>>
>> Well, okay, it might be a bit better, Jason. Frankly, it still looks
>> like hell. I think, that if somebody offered up this as an example of
>> their Velocity usage, one really ought to suggest similar refactorings
>> along the lines of what I did above, to make it more readable and
>> maintainable.
>>
>> Well, on second thought, I suppose that a lot of existing code out
>> there probably does look like this. (Or worse.) I often am stunned
>> when people send in code fragments of what they're doing -- Java or
>> FreeMarker or something else. It is not exactly clear what I can do
>> about this. People will always be able to write muddled obfuscated
>> code that is hard to read or maintain in any language.
>>
>> Anyway, as I pointed out in another response to Chad, we simply have
>> no evidence that people confusing FreeMarker instructions with HTML
>> tags is a real-world problem out there.
>>
>> Jonathan Revusky
>> --
>> lead developer, FreeMarker project, http://freemarker.org/
>>
>>>
>>> --jason
>>>
>>> Jonathan Revusky wrote:
>>>
>>>> Chad Meadows wrote:
>>>>
>>>>> The analogy is not accurate.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Okay, analogies, by their nature are not "accurate". "Life is like a
>>>> box of chocolates..." and so on. My point was really just that it is
>>>> surprising that someone who primarily knows HTML or XML would find
>>>> FreeMarker's pseudo-tag approach unpalatable. The basic *approach*
>>>> of a FreeMarker if statement, say, is familiar to such a person:
>>>>
>>>> <#if user.isLoggedIn>
>>>> ...
>>>> </#if>
>>>>
>>>> After all, it's an approach that they are used to, bounding things
>>>> with <foo>...</foo>. And this could make for more initial comfort
>>>> level than another, completely unfamiliar syntax.
>>>>
>>>> And this is the same mechanism that makes Java initially more
>>>> palatable to a C hacker than Smalltalk, say. That was my point.
>>>>
>>>>> If Java was written by interweaving it within a C program this
>>>>> would be an accurate analogy. In which case, I would suspect
>>>>> everyone would then consider that a syntax nightmare.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Well, okay, this is stretching the analogy further than I would have
>>>> intended. It's all apples and oranges. Java is note a templating
>>>> language. But fine, mea culpa, the analogy is obviously quite
>>>> imperfect.
>>>>
>>>> So, let's not work that analogy further. Let me take another tack on
>>>> this topic....
>>>>
>>>> Okay? Here goes....
>>>>
>>>> Chad, this whole idea being bandied about, that people working on
>>>> FreeMarker page templates have a problem distinguishing the
>>>> FreeMarker directives from the HTML tags is, to the best of my
>>>> knowledge, a complete and utter non-issue.
>>>>
>>>> I just realized that I have now been involved with FreeMarker for 6
>>>> years, first simply as a user (which is the period in which I
>>>> actually interacted most with designers who were using FM templates)
>>>> and then later as a developer, and eventually, as project lead,
>>>> rewriting the parser/renderer core of the engine for the 2.x releases.
>>>>
>>>> In all of that time, I have never heard somebody who actually uses
>>>> FreeMarker complain that they confuse the FreeMarker instructions
>>>> with HTML tags -- that this is a problem. I believe you could google
>>>> on our mailing list archives and the list archives of high profile
>>>> projects that use FreeMarker as a view (like OfBiz and now, Webwork)
>>>> and you will simply not see anybody complaining about this. (They
>>>> may have other FreeMarker-related issues, sure, but not this one.)
>>>>
>>>> I grant now, that this is not 100% absolute proof that this is not a
>>>> real-world problem. However, I can only go by what evidence I have.
>>>> Don't you think that, if this really were a widespread problem,
>>>> that, in 6 years, it would have come to my attention?
>>>>
>>>> Now, what is interesting is that, people have lobbied for an
>>>> alternative syntax that didn't delimit with <...>. And the latest
>>>> version in CVS (and soon to be released) allows [#...] as an
>>>> alternative to <#....>.
>>>>
>>>> BUT if you look at the messages where people lobbied for this, there
>>>> was never any mention of human template writers being confused by
>>>> the syntax. It was entirely to make the templates compatible with
>>>> certain tools -- for example, HTML-oriented editing tools that got
>>>> confused by pseudo-tags.
>>>>
>>>> IOW, the syntactical issue has come up, but it was always because
>>>> the syntax confused certain tools -- never, to my recollection that
>>>> it confused people. I reason that if that had been an issue, this
>>>> would have also come out in such conversations. It never did.
>>>>
>>>> But, you don't really have to take my word for this, Chad. Nor
>>>> should you -- at least, if this still is a major concern of yours
>>>> wrt FreeMarker. If you are at IBM and have web page designers on
>>>> staff, see if you can have one or more of them work with FreeMarker
>>>> on a pilot project for a certain period of time and see whether
>>>> there really is a problem of people confusing FreeMarker directives
>>>> with HTML or XML tags.
>>>>
>>>> I will re-iterate that FreeMarker tags all start with quite
>>>> distinctive character sequences:
>>>>
>>>> <#
>>>>
>>>> and
>>>>
>>>> <@
>>>>
>>>> that are not valid XML/HTML anyway. These patterns can be syntax
>>>> highlighted in a separate color. (And of course, they should be.)
>>>>
>>>> Now, if there is real solid evidence that this is a genuine problem,
>>>> that people still get all dazed and confused because they can't
>>>> distinguish a FM directive from an HTML tag, like *even* if you
>>>> syntax-highlight HTML tags in orange and FTL in purple, I will be
>>>> very interested in hearing about this.
>>>>
>>>> But, really, you must understand that, until then, given the data
>>>> that I have on this question, it just does not seem like a fruitful
>>>> line of inquiry or discussion. It seems utterly sterile because it
>>>> simply does not appear that this is a real-world problem.
>>>>
>>>> Regards,
>>>>
>>>> Jonathan Revusky
>>>> --
>>>> lead developer, FreeMarker project, http://freemarker.org/
>>>>
>>>>
>>>>>
>>>>> Chad.
>>>>>
>>>>>
>>>>>
>>>>> Austin Taylor <au...@gmail.com> 10/08/2005 05:14 PM
>>>>> Please respond to
>>>>> "Velocity Users List"
>>>>>
>>>>>
>>>>> To
>>>>> Velocity Users List <ve...@jakarta.apache.org>
>>>>> cc
>>>>>
>>>>> Subject
>>>>> Re: [ANN] Viento - WHY?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Jonathan, you really are coming across as polemic. Try to be more
>>>>> contemplative (like maybe you actually considered the other
>>>>> person's point
>>>>> of view) than defensive.
>>>>>
>>>>> Well, in other contexts, such things have been deemed to be an
>>>>>
>>>>>> advantage. Java syntax was based on that of C to make it more
>>>>>> palatable
>>>>>> to all the existing C hackers. Java, in fact, looks like C but is
>>>>>> not C.
>>>>>>
>>>>>> Most people would guess that this strategy did work, in fact. So,
>>>>>> why is
>>>>>> this case so different? If FTL looks like HTML but is not HTML,
>>>>>> why does
>>>>>> this lead HTML hackers to reject it, yet when Java looks like C
>>>>>> but is
>>>>>> not C this would tend to enhance Java's acceptability?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> That's a very interesting point. I suppose, for HTML people,
>>>>> FreeMarker's
>>>>> syntax might be great. As a programmer, I prefer something that
>>>>> feels more
>>>>> like a 'real' programming language. The syntax in Viento is
>>>>> designed to be
>>>>> like Java, with a little sugar from Ruby to make it worthwhile, and
>>>>> a few $
>>>>> from perl to make it a template language.
>>>>>
>>>>> Austin
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Jason Pettiss <ja...@TheCatalis.com>.
Hey, I agree with you. With a little more thinking, a little more
up-front typing, you can make things readable and at the same time more
concise. And inherently *better*. (Btw, the #assign feature is supercool.)
Have you see the HTML written by content authors that aren't
developers? Or worse-- what they produce when using the "aid" of a
wysiwyg editor? They're not going to do all that super-nice stuff you
used there-- because it doesn't appear "right" in their super-nifty
editor... in fact until you add a framework to the template language
which mock-evaluates the template in the wysiwyg editor, these extra
features will just go to waste...
And until then, they'll just bitch and moan about the "extra" < / > all
over the place. And in most cases they're unnecessary anyway-- so why
should I have to type them? You say that's a shallow question, but some
languages do measure power by the savings of an extra character of
syntax here and there, even at the expense of readability.
I just don't see why I should have to stroke the parser's ego with these
extra characters, when it detracts from readability and isn't strictly
necessary. I don't really care about having one right way as much as
having the way that suits my needs at the present moment.
--jason
Jonathan Revusky wrote:
> Jason Pettiss wrote:
>
>> Syntax highlighting isn't very flexible in many popular editors,
>
>
> I haven't done a survey of this issue. Which editors are you referring
> to specifically?
>
> Though, my honest reaction is that, I, personally, if I were writing
> in language FOOBAR as part of my daily work, I would make sure to use
> an editing tool that can syntax-highlight FOOBAR source code. That
> would be my "best practices" suggestion. Now, if people choose not to
> follow my "best practices" suggestion, that is their right.
>
>
>> and often the HTML-specific ones will not allow you to color <...>
>> differently from <#...>. Some potential users might have trouble
>> choosing colors for their MSN... your blithe hand-waving about proper
>> use of syntax highlighting will get you glazed eyeballs at best.
>>
>> Also what of this:
>>
>> <td <#if item.imagetype = "big">colspan="2"</#if>>
>> <span style="font-family:Helvetica,sans-serif;
>> <#if item.sale = "limited">color:#cc9933;
>> <#elseif item.sale = "new">color:#eeff00;</#if>">
>> <#if item.selected><b <#if
>> item.current>style="font-size:1.0em;"</#if>></#if>
>> ${item.name}<#if item.selected></b></#if>
>> </span>
>>
>> How exactly is this going to look with syntax highlighting, given
>> that HTML and FTL are nested within each other, and-- nested within
>> quoting, which vexes even the best editors...
>
>
> I'll concede you do have a point. I copy-pasted the above fragment
> into what is doubtless one of the very best editors, JEdit
> (http://www.jedit.org) which has syntax-highlighting for FreeMarker
> out-of-the-box.
>
> It fails to syntax highlight everything in the above mish-mash correctly.
>
> Still, the fact is that the above code fragment is hardly
> recommendable. If somebody sent this in as an example of what they
> were doing on the freemarker-user mailing list, I do not think that I
> could refrain from offering some stylistic advice.
>
> Actually, here is one way of refactoring your code fragment so that it
> is more readable and maintainable.
>
> <#if item.imagetype="big">
> <#assign colspan="2">
> <#else>
> <#assign colspan="1">
> </#if>
>
> <#assign style>
> font-family:Helvetica,sans-serif;
> <#if item.sale = "limited">color:#cc9933;
> <#elseif item.sale = "new">color:#eeff00;</#if>"
> </#assign>
>
> <#macro showItem item>
> <#local style="">
> <#if item.current>
> <#local style='style="font-size:1.0em;"'>
> </#if>
> <#if item.selected><b ${style}></#if>
> ${item.name}
> <#if item.selected></b></#if>
> </#macro>
>
>
> <#--
> Now, having set up the above helpers, here is the templatized
> HTML we output. This is really much better style.
> -->
>
> <td colspan="${colspan}">
> <span style="${style}">
> <@showItem item />
> </span>
>
>
> Perhaps needless to say, jEdit has no problem syntax highlighting the
> above refactored version. So, my tentative conclusion from this is
> that you can write FreeMarker template code that confuses the syntax
> highlighting rules in JEdit, say. Also, such code is obfuscated for a
> human reading it.
>
> OTOH, such code should be refactored generally.
>
>
>>
>> Also note the $ which usually indicates to the user, a variable, is
>> missing from inside the directives, which makes the directives
>> "disappear" even more.
>> Finally note that the need to both open and close each opening and
>> closing directive with the same opening and closing delimiters used
>> by HTML is really fricking confusing, and downright annoying to have
>> to type!
>
>
> I would discourage people from writing templates that look like the
> example you provided. Consider my refactored version.
>
>>
>> I don't really like having to type < and >. I think the choice to
>> allow [ and ] is a good one. But I much prefer this, due to the
>> other reasons listed above:
>>
>> <td #if( $item.ImageType == "big" )colspan="2"#end>
>> <span style="font-family:Helvetica,sans-serif;
>> #if( $item.Sale == 'limited' )color:#cc9933;
>> #elseif( $item.Sale == 'new' )color:#eeff00;#end">
>> #if( $item.Selected )<b #if( $item.Current
>> )style="font-size:1.0em;"#end>#end
>> ${item.Name}#if( $item.Selected )</b>#end
>> </span>
>
>
> Well, okay, it might be a bit better, Jason. Frankly, it still looks
> like hell. I think, that if somebody offered up this as an example of
> their Velocity usage, one really ought to suggest similar refactorings
> along the lines of what I did above, to make it more readable and
> maintainable.
>
> Well, on second thought, I suppose that a lot of existing code out
> there probably does look like this. (Or worse.) I often am stunned
> when people send in code fragments of what they're doing -- Java or
> FreeMarker or something else. It is not exactly clear what I can do
> about this. People will always be able to write muddled obfuscated
> code that is hard to read or maintain in any language.
>
> Anyway, as I pointed out in another response to Chad, we simply have
> no evidence that people confusing FreeMarker instructions with HTML
> tags is a real-world problem out there.
>
> Jonathan Revusky
> --
> lead developer, FreeMarker project, http://freemarker.org/
>
>>
>> --jason
>>
>> Jonathan Revusky wrote:
>>
>>> Chad Meadows wrote:
>>>
>>>> The analogy is not accurate.
>>>
>>>
>>>
>>>
>>> Okay, analogies, by their nature are not "accurate". "Life is like a
>>> box of chocolates..." and so on. My point was really just that it is
>>> surprising that someone who primarily knows HTML or XML would find
>>> FreeMarker's pseudo-tag approach unpalatable. The basic *approach*
>>> of a FreeMarker if statement, say, is familiar to such a person:
>>>
>>> <#if user.isLoggedIn>
>>> ...
>>> </#if>
>>>
>>> After all, it's an approach that they are used to, bounding things
>>> with <foo>...</foo>. And this could make for more initial comfort
>>> level than another, completely unfamiliar syntax.
>>>
>>> And this is the same mechanism that makes Java initially more
>>> palatable to a C hacker than Smalltalk, say. That was my point.
>>>
>>>> If Java was written by interweaving it within a C program this
>>>> would be an accurate analogy. In which case, I would suspect
>>>> everyone would then consider that a syntax nightmare.
>>>
>>>
>>>
>>>
>>>
>>> Well, okay, this is stretching the analogy further than I would have
>>> intended. It's all apples and oranges. Java is note a templating
>>> language. But fine, mea culpa, the analogy is obviously quite
>>> imperfect.
>>>
>>> So, let's not work that analogy further. Let me take another tack on
>>> this topic....
>>>
>>> Okay? Here goes....
>>>
>>> Chad, this whole idea being bandied about, that people working on
>>> FreeMarker page templates have a problem distinguishing the
>>> FreeMarker directives from the HTML tags is, to the best of my
>>> knowledge, a complete and utter non-issue.
>>>
>>> I just realized that I have now been involved with FreeMarker for 6
>>> years, first simply as a user (which is the period in which I
>>> actually interacted most with designers who were using FM templates)
>>> and then later as a developer, and eventually, as project lead,
>>> rewriting the parser/renderer core of the engine for the 2.x releases.
>>>
>>> In all of that time, I have never heard somebody who actually uses
>>> FreeMarker complain that they confuse the FreeMarker instructions
>>> with HTML tags -- that this is a problem. I believe you could google
>>> on our mailing list archives and the list archives of high profile
>>> projects that use FreeMarker as a view (like OfBiz and now, Webwork)
>>> and you will simply not see anybody complaining about this. (They
>>> may have other FreeMarker-related issues, sure, but not this one.)
>>>
>>> I grant now, that this is not 100% absolute proof that this is not a
>>> real-world problem. However, I can only go by what evidence I have.
>>> Don't you think that, if this really were a widespread problem,
>>> that, in 6 years, it would have come to my attention?
>>>
>>> Now, what is interesting is that, people have lobbied for an
>>> alternative syntax that didn't delimit with <...>. And the latest
>>> version in CVS (and soon to be released) allows [#...] as an
>>> alternative to <#....>.
>>>
>>> BUT if you look at the messages where people lobbied for this, there
>>> was never any mention of human template writers being confused by
>>> the syntax. It was entirely to make the templates compatible with
>>> certain tools -- for example, HTML-oriented editing tools that got
>>> confused by pseudo-tags.
>>>
>>> IOW, the syntactical issue has come up, but it was always because
>>> the syntax confused certain tools -- never, to my recollection that
>>> it confused people. I reason that if that had been an issue, this
>>> would have also come out in such conversations. It never did.
>>>
>>> But, you don't really have to take my word for this, Chad. Nor
>>> should you -- at least, if this still is a major concern of yours
>>> wrt FreeMarker. If you are at IBM and have web page designers on
>>> staff, see if you can have one or more of them work with FreeMarker
>>> on a pilot project for a certain period of time and see whether
>>> there really is a problem of people confusing FreeMarker directives
>>> with HTML or XML tags.
>>>
>>> I will re-iterate that FreeMarker tags all start with quite
>>> distinctive character sequences:
>>>
>>> <#
>>>
>>> and
>>>
>>> <@
>>>
>>> that are not valid XML/HTML anyway. These patterns can be syntax
>>> highlighted in a separate color. (And of course, they should be.)
>>>
>>> Now, if there is real solid evidence that this is a genuine problem,
>>> that people still get all dazed and confused because they can't
>>> distinguish a FM directive from an HTML tag, like *even* if you
>>> syntax-highlight HTML tags in orange and FTL in purple, I will be
>>> very interested in hearing about this.
>>>
>>> But, really, you must understand that, until then, given the data
>>> that I have on this question, it just does not seem like a fruitful
>>> line of inquiry or discussion. It seems utterly sterile because it
>>> simply does not appear that this is a real-world problem.
>>>
>>> Regards,
>>>
>>> Jonathan Revusky
>>> --
>>> lead developer, FreeMarker project, http://freemarker.org/
>>>
>>>
>>>>
>>>> Chad.
>>>>
>>>>
>>>>
>>>> Austin Taylor <au...@gmail.com> 10/08/2005 05:14 PM
>>>> Please respond to
>>>> "Velocity Users List"
>>>>
>>>>
>>>> To
>>>> Velocity Users List <ve...@jakarta.apache.org>
>>>> cc
>>>>
>>>> Subject
>>>> Re: [ANN] Viento - WHY?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Jonathan, you really are coming across as polemic. Try to be more
>>>> contemplative (like maybe you actually considered the other
>>>> person's point
>>>> of view) than defensive.
>>>>
>>>> Well, in other contexts, such things have been deemed to be an
>>>>
>>>>> advantage. Java syntax was based on that of C to make it more
>>>>> palatable
>>>>> to all the existing C hackers. Java, in fact, looks like C but is
>>>>> not C.
>>>>>
>>>>> Most people would guess that this strategy did work, in fact. So,
>>>>> why is
>>>>> this case so different? If FTL looks like HTML but is not HTML,
>>>>> why does
>>>>> this lead HTML hackers to reject it, yet when Java looks like C
>>>>> but is
>>>>> not C this would tend to enhance Java's acceptability?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> That's a very interesting point. I suppose, for HTML people,
>>>> FreeMarker's
>>>> syntax might be great. As a programmer, I prefer something that
>>>> feels more
>>>> like a 'real' programming language. The syntax in Viento is
>>>> designed to be
>>>> like Java, with a little sugar from Ruby to make it worthwhile, and
>>>> a few $
>>>> from perl to make it a template language.
>>>>
>>>> Austin
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Jason Pettiss wrote:
> Syntax highlighting isn't very flexible in many popular editors,
I haven't done a survey of this issue. Which editors are you referring
to specifically?
Though, my honest reaction is that, I, personally, if I were writing in
language FOOBAR as part of my daily work, I would make sure to use an
editing tool that can syntax-highlight FOOBAR source code. That would be
my "best practices" suggestion. Now, if people choose not to follow my
"best practices" suggestion, that is their right.
> and
> often the HTML-specific ones will not allow you to color <...>
> differently from <#...>. Some potential users might have trouble
> choosing colors for their MSN... your blithe hand-waving about proper
> use of syntax highlighting will get you glazed eyeballs at best.
>
> Also what of this:
>
> <td <#if item.imagetype = "big">colspan="2"</#if>>
> <span style="font-family:Helvetica,sans-serif;
> <#if item.sale = "limited">color:#cc9933;
> <#elseif item.sale = "new">color:#eeff00;</#if>">
> <#if item.selected><b <#if
> item.current>style="font-size:1.0em;"</#if>></#if>
> ${item.name}<#if item.selected></b></#if>
> </span>
>
> How exactly is this going to look with syntax highlighting, given that
> HTML and FTL are nested within each other, and-- nested within quoting,
> which vexes even the best editors...
I'll concede you do have a point. I copy-pasted the above fragment into
what is doubtless one of the very best editors, JEdit
(http://www.jedit.org) which has syntax-highlighting for FreeMarker
out-of-the-box.
It fails to syntax highlight everything in the above mish-mash correctly.
Still, the fact is that the above code fragment is hardly recommendable.
If somebody sent this in as an example of what they were doing on the
freemarker-user mailing list, I do not think that I could refrain from
offering some stylistic advice.
Actually, here is one way of refactoring your code fragment so that it
is more readable and maintainable.
<#if item.imagetype="big">
<#assign colspan="2">
<#else>
<#assign colspan="1">
</#if>
<#assign style>
font-family:Helvetica,sans-serif;
<#if item.sale = "limited">color:#cc9933;
<#elseif item.sale = "new">color:#eeff00;</#if>"
</#assign>
<#macro showItem item>
<#local style="">
<#if item.current>
<#local style='style="font-size:1.0em;"'>
</#if>
<#if item.selected><b ${style}></#if>
${item.name}
<#if item.selected></b></#if>
</#macro>
<#--
Now, having set up the above helpers, here is the templatized
HTML we output. This is really much better style.
-->
<td colspan="${colspan}">
<span style="${style}">
<@showItem item />
</span>
Perhaps needless to say, jEdit has no problem syntax highlighting the
above refactored version. So, my tentative conclusion from this is that
you can write FreeMarker template code that confuses the syntax
highlighting rules in JEdit, say. Also, such code is obfuscated for a
human reading it.
OTOH, such code should be refactored generally.
>
> Also note the $ which usually indicates to the user, a variable, is
> missing from inside the directives, which makes the directives
> "disappear" even more.
> Finally note that the need to both open and close each opening and
> closing directive with the same opening and closing delimiters used by
> HTML is really fricking confusing, and downright annoying to have to type!
I would discourage people from writing templates that look like the
example you provided. Consider my refactored version.
>
> I don't really like having to type < and >. I think the choice to allow
> [ and ] is a good one. But I much prefer this, due to the other reasons
> listed above:
>
> <td #if( $item.ImageType == "big" )colspan="2"#end>
> <span style="font-family:Helvetica,sans-serif;
> #if( $item.Sale == 'limited' )color:#cc9933;
> #elseif( $item.Sale == 'new' )color:#eeff00;#end">
> #if( $item.Selected )<b #if( $item.Current
> )style="font-size:1.0em;"#end>#end
> ${item.Name}#if( $item.Selected )</b>#end
> </span>
Well, okay, it might be a bit better, Jason. Frankly, it still looks
like hell. I think, that if somebody offered up this as an example of
their Velocity usage, one really ought to suggest similar refactorings
along the lines of what I did above, to make it more readable and
maintainable.
Well, on second thought, I suppose that a lot of existing code out there
probably does look like this. (Or worse.) I often am stunned when people
send in code fragments of what they're doing -- Java or FreeMarker or
something else. It is not exactly clear what I can do about this. People
will always be able to write muddled obfuscated code that is hard to
read or maintain in any language.
Anyway, as I pointed out in another response to Chad, we simply have no
evidence that people confusing FreeMarker instructions with HTML tags is
a real-world problem out there.
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
> --jason
>
> Jonathan Revusky wrote:
>
>> Chad Meadows wrote:
>>
>>> The analogy is not accurate.
>>
>>
>>
>> Okay, analogies, by their nature are not "accurate". "Life is like a
>> box of chocolates..." and so on. My point was really just that it is
>> surprising that someone who primarily knows HTML or XML would find
>> FreeMarker's pseudo-tag approach unpalatable. The basic *approach* of
>> a FreeMarker if statement, say, is familiar to such a person:
>>
>> <#if user.isLoggedIn>
>> ...
>> </#if>
>>
>> After all, it's an approach that they are used to, bounding things
>> with <foo>...</foo>. And this could make for more initial comfort
>> level than another, completely unfamiliar syntax.
>>
>> And this is the same mechanism that makes Java initially more
>> palatable to a C hacker than Smalltalk, say. That was my point.
>>
>>> If Java was written by interweaving it within a C program this would
>>> be an accurate analogy. In which case, I would suspect everyone
>>> would then consider that a syntax nightmare.
>>
>>
>>
>>
>> Well, okay, this is stretching the analogy further than I would have
>> intended. It's all apples and oranges. Java is note a templating
>> language. But fine, mea culpa, the analogy is obviously quite imperfect.
>>
>> So, let's not work that analogy further. Let me take another tack on
>> this topic....
>>
>> Okay? Here goes....
>>
>> Chad, this whole idea being bandied about, that people working on
>> FreeMarker page templates have a problem distinguishing the FreeMarker
>> directives from the HTML tags is, to the best of my knowledge, a
>> complete and utter non-issue.
>>
>> I just realized that I have now been involved with FreeMarker for 6
>> years, first simply as a user (which is the period in which I actually
>> interacted most with designers who were using FM templates) and then
>> later as a developer, and eventually, as project lead, rewriting the
>> parser/renderer core of the engine for the 2.x releases.
>>
>> In all of that time, I have never heard somebody who actually uses
>> FreeMarker complain that they confuse the FreeMarker instructions with
>> HTML tags -- that this is a problem. I believe you could google on our
>> mailing list archives and the list archives of high profile projects
>> that use FreeMarker as a view (like OfBiz and now, Webwork) and you
>> will simply not see anybody complaining about this. (They may have
>> other FreeMarker-related issues, sure, but not this one.)
>>
>> I grant now, that this is not 100% absolute proof that this is not a
>> real-world problem. However, I can only go by what evidence I have.
>> Don't you think that, if this really were a widespread problem, that,
>> in 6 years, it would have come to my attention?
>>
>> Now, what is interesting is that, people have lobbied for an
>> alternative syntax that didn't delimit with <...>. And the latest
>> version in CVS (and soon to be released) allows [#...] as an
>> alternative to <#....>.
>>
>> BUT if you look at the messages where people lobbied for this, there
>> was never any mention of human template writers being confused by the
>> syntax. It was entirely to make the templates compatible with certain
>> tools -- for example, HTML-oriented editing tools that got confused by
>> pseudo-tags.
>>
>> IOW, the syntactical issue has come up, but it was always because the
>> syntax confused certain tools -- never, to my recollection that it
>> confused people. I reason that if that had been an issue, this would
>> have also come out in such conversations. It never did.
>>
>> But, you don't really have to take my word for this, Chad. Nor should
>> you -- at least, if this still is a major concern of yours wrt
>> FreeMarker. If you are at IBM and have web page designers on staff,
>> see if you can have one or more of them work with FreeMarker on a
>> pilot project for a certain period of time and see whether there
>> really is a problem of people confusing FreeMarker directives with
>> HTML or XML tags.
>>
>> I will re-iterate that FreeMarker tags all start with quite
>> distinctive character sequences:
>>
>> <#
>>
>> and
>>
>> <@
>>
>> that are not valid XML/HTML anyway. These patterns can be syntax
>> highlighted in a separate color. (And of course, they should be.)
>>
>> Now, if there is real solid evidence that this is a genuine problem,
>> that people still get all dazed and confused because they can't
>> distinguish a FM directive from an HTML tag, like *even* if you
>> syntax-highlight HTML tags in orange and FTL in purple, I will be very
>> interested in hearing about this.
>>
>> But, really, you must understand that, until then, given the data that
>> I have on this question, it just does not seem like a fruitful line of
>> inquiry or discussion. It seems utterly sterile because it simply does
>> not appear that this is a real-world problem.
>>
>> Regards,
>>
>> Jonathan Revusky
>> --
>> lead developer, FreeMarker project, http://freemarker.org/
>>
>>
>>>
>>> Chad.
>>>
>>>
>>>
>>> Austin Taylor <au...@gmail.com> 10/08/2005 05:14 PM
>>> Please respond to
>>> "Velocity Users List"
>>>
>>>
>>> To
>>> Velocity Users List <ve...@jakarta.apache.org>
>>> cc
>>>
>>> Subject
>>> Re: [ANN] Viento - WHY?
>>>
>>>
>>>
>>>
>>>
>>>
>>> Jonathan, you really are coming across as polemic. Try to be more
>>> contemplative (like maybe you actually considered the other person's
>>> point
>>> of view) than defensive.
>>>
>>> Well, in other contexts, such things have been deemed to be an
>>>
>>>> advantage. Java syntax was based on that of C to make it more palatable
>>>> to all the existing C hackers. Java, in fact, looks like C but is
>>>> not C.
>>>>
>>>> Most people would guess that this strategy did work, in fact. So,
>>>> why is
>>>> this case so different? If FTL looks like HTML but is not HTML, why
>>>> does
>>>> this lead HTML hackers to reject it, yet when Java looks like C but is
>>>> not C this would tend to enhance Java's acceptability?
>>>
>>>
>>>
>>>
>>>
>>> That's a very interesting point. I suppose, for HTML people,
>>> FreeMarker's
>>> syntax might be great. As a programmer, I prefer something that feels
>>> more
>>> like a 'real' programming language. The syntax in Viento is designed
>>> to be
>>> like Java, with a little sugar from Ruby to make it worthwhile, and a
>>> few $
>>> from perl to make it a template language.
>>>
>>> Austin
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Jason Pettiss <ja...@TheCatalis.com>.
Syntax highlighting isn't very flexible in many popular editors, and
often the HTML-specific ones will not allow you to color <...>
differently from <#...>. Some potential users might have trouble
choosing colors for their MSN... your blithe hand-waving about proper
use of syntax highlighting will get you glazed eyeballs at best.
Also what of this:
<td <#if item.imagetype = "big">colspan="2"</#if>>
<span style="font-family:Helvetica,sans-serif;
<#if item.sale = "limited">color:#cc9933;
<#elseif item.sale = "new">color:#eeff00;</#if>">
<#if item.selected><b <#if
item.current>style="font-size:1.0em;"</#if>></#if>
${item.name}<#if item.selected></b></#if>
</span>
How exactly is this going to look with syntax highlighting, given that
HTML and FTL are nested within each other, and-- nested within quoting,
which vexes even the best editors...
Also note the $ which usually indicates to the user, a variable, is
missing from inside the directives, which makes the directives
"disappear" even more.
Finally note that the need to both open and close each opening and
closing directive with the same opening and closing delimiters used by
HTML is really fricking confusing, and downright annoying to have to type!
I don't really like having to type < and >. I think the choice to allow
[ and ] is a good one. But I much prefer this, due to the other reasons
listed above:
<td #if( $item.ImageType == "big" )colspan="2"#end>
<span style="font-family:Helvetica,sans-serif;
#if( $item.Sale == 'limited' )color:#cc9933;
#elseif( $item.Sale == 'new' )color:#eeff00;#end">
#if( $item.Selected )<b #if( $item.Current
)style="font-size:1.0em;"#end>#end
${item.Name}#if( $item.Selected )</b>#end
</span>
--jason
Jonathan Revusky wrote:
> Chad Meadows wrote:
>
>> The analogy is not accurate.
>
>
> Okay, analogies, by their nature are not "accurate". "Life is like a
> box of chocolates..." and so on. My point was really just that it is
> surprising that someone who primarily knows HTML or XML would find
> FreeMarker's pseudo-tag approach unpalatable. The basic *approach* of
> a FreeMarker if statement, say, is familiar to such a person:
>
> <#if user.isLoggedIn>
> ...
> </#if>
>
> After all, it's an approach that they are used to, bounding things
> with <foo>...</foo>. And this could make for more initial comfort
> level than another, completely unfamiliar syntax.
>
> And this is the same mechanism that makes Java initially more
> palatable to a C hacker than Smalltalk, say. That was my point.
>
>> If Java was written by interweaving it within a C program this would
>> be an accurate analogy. In which case, I would suspect everyone
>> would then consider that a syntax nightmare.
>
>
>
> Well, okay, this is stretching the analogy further than I would have
> intended. It's all apples and oranges. Java is note a templating
> language. But fine, mea culpa, the analogy is obviously quite imperfect.
>
> So, let's not work that analogy further. Let me take another tack on
> this topic....
>
> Okay? Here goes....
>
> Chad, this whole idea being bandied about, that people working on
> FreeMarker page templates have a problem distinguishing the FreeMarker
> directives from the HTML tags is, to the best of my knowledge, a
> complete and utter non-issue.
>
> I just realized that I have now been involved with FreeMarker for 6
> years, first simply as a user (which is the period in which I actually
> interacted most with designers who were using FM templates) and then
> later as a developer, and eventually, as project lead, rewriting the
> parser/renderer core of the engine for the 2.x releases.
>
> In all of that time, I have never heard somebody who actually uses
> FreeMarker complain that they confuse the FreeMarker instructions with
> HTML tags -- that this is a problem. I believe you could google on our
> mailing list archives and the list archives of high profile projects
> that use FreeMarker as a view (like OfBiz and now, Webwork) and you
> will simply not see anybody complaining about this. (They may have
> other FreeMarker-related issues, sure, but not this one.)
>
> I grant now, that this is not 100% absolute proof that this is not a
> real-world problem. However, I can only go by what evidence I have.
> Don't you think that, if this really were a widespread problem, that,
> in 6 years, it would have come to my attention?
>
> Now, what is interesting is that, people have lobbied for an
> alternative syntax that didn't delimit with <...>. And the latest
> version in CVS (and soon to be released) allows [#...] as an
> alternative to <#....>.
>
> BUT if you look at the messages where people lobbied for this, there
> was never any mention of human template writers being confused by the
> syntax. It was entirely to make the templates compatible with certain
> tools -- for example, HTML-oriented editing tools that got confused by
> pseudo-tags.
>
> IOW, the syntactical issue has come up, but it was always because the
> syntax confused certain tools -- never, to my recollection that it
> confused people. I reason that if that had been an issue, this would
> have also come out in such conversations. It never did.
>
> But, you don't really have to take my word for this, Chad. Nor should
> you -- at least, if this still is a major concern of yours wrt
> FreeMarker. If you are at IBM and have web page designers on staff,
> see if you can have one or more of them work with FreeMarker on a
> pilot project for a certain period of time and see whether there
> really is a problem of people confusing FreeMarker directives with
> HTML or XML tags.
>
> I will re-iterate that FreeMarker tags all start with quite
> distinctive character sequences:
>
> <#
>
> and
>
> <@
>
> that are not valid XML/HTML anyway. These patterns can be syntax
> highlighted in a separate color. (And of course, they should be.)
>
> Now, if there is real solid evidence that this is a genuine problem,
> that people still get all dazed and confused because they can't
> distinguish a FM directive from an HTML tag, like *even* if you
> syntax-highlight HTML tags in orange and FTL in purple, I will be very
> interested in hearing about this.
>
> But, really, you must understand that, until then, given the data that
> I have on this question, it just does not seem like a fruitful line of
> inquiry or discussion. It seems utterly sterile because it simply does
> not appear that this is a real-world problem.
>
> Regards,
>
> Jonathan Revusky
> --
> lead developer, FreeMarker project, http://freemarker.org/
>
>
>>
>> Chad.
>>
>>
>>
>> Austin Taylor <au...@gmail.com> 10/08/2005 05:14 PM
>> Please respond to
>> "Velocity Users List"
>>
>>
>> To
>> Velocity Users List <ve...@jakarta.apache.org>
>> cc
>>
>> Subject
>> Re: [ANN] Viento - WHY?
>>
>>
>>
>>
>>
>>
>> Jonathan, you really are coming across as polemic. Try to be more
>> contemplative (like maybe you actually considered the other person's
>> point
>> of view) than defensive.
>>
>> Well, in other contexts, such things have been deemed to be an
>>
>>> advantage. Java syntax was based on that of C to make it more palatable
>>> to all the existing C hackers. Java, in fact, looks like C but is
>>> not C.
>>>
>>> Most people would guess that this strategy did work, in fact. So,
>>> why is
>>> this case so different? If FTL looks like HTML but is not HTML, why
>>> does
>>> this lead HTML hackers to reject it, yet when Java looks like C but is
>>> not C this would tend to enhance Java's acceptability?
>>
>>
>>
>>
>> That's a very interesting point. I suppose, for HTML people,
>> FreeMarker's
>> syntax might be great. As a programmer, I prefer something that feels
>> more
>> like a 'real' programming language. The syntax in Viento is designed
>> to be
>> like Java, with a little sugar from Ruby to make it worthwhile, and a
>> few $
>> from perl to make it a template language.
>>
>> Austin
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Chad Meadows wrote:
> The analogy is not accurate.
Okay, analogies, by their nature are not "accurate". "Life is like a box
of chocolates..." and so on. My point was really just that it is
surprising that someone who primarily knows HTML or XML would find
FreeMarker's pseudo-tag approach unpalatable. The basic *approach* of a
FreeMarker if statement, say, is familiar to such a person:
<#if user.isLoggedIn>
...
</#if>
After all, it's an approach that they are used to, bounding things with
<foo>...</foo>. And this could make for more initial comfort level than
another, completely unfamiliar syntax.
And this is the same mechanism that makes Java initially more palatable
to a C hacker than Smalltalk, say. That was my point.
> If Java was written by interweaving it
> within a C program this would be an accurate analogy. In which case, I
> would suspect everyone would then consider that a syntax nightmare.
Well, okay, this is stretching the analogy further than I would have
intended. It's all apples and oranges. Java is note a templating
language. But fine, mea culpa, the analogy is obviously quite imperfect.
So, let's not work that analogy further. Let me take another tack on
this topic....
Okay? Here goes....
Chad, this whole idea being bandied about, that people working on
FreeMarker page templates have a problem distinguishing the FreeMarker
directives from the HTML tags is, to the best of my knowledge, a
complete and utter non-issue.
I just realized that I have now been involved with FreeMarker for 6
years, first simply as a user (which is the period in which I actually
interacted most with designers who were using FM templates) and then
later as a developer, and eventually, as project lead, rewriting the
parser/renderer core of the engine for the 2.x releases.
In all of that time, I have never heard somebody who actually uses
FreeMarker complain that they confuse the FreeMarker instructions with
HTML tags -- that this is a problem. I believe you could google on our
mailing list archives and the list archives of high profile projects
that use FreeMarker as a view (like OfBiz and now, Webwork) and you will
simply not see anybody complaining about this. (They may have other
FreeMarker-related issues, sure, but not this one.)
I grant now, that this is not 100% absolute proof that this is not a
real-world problem. However, I can only go by what evidence I have.
Don't you think that, if this really were a widespread problem, that, in
6 years, it would have come to my attention?
Now, what is interesting is that, people have lobbied for an alternative
syntax that didn't delimit with <...>. And the latest version in CVS
(and soon to be released) allows [#...] as an alternative to <#....>.
BUT if you look at the messages where people lobbied for this, there was
never any mention of human template writers being confused by the
syntax. It was entirely to make the templates compatible with certain
tools -- for example, HTML-oriented editing tools that got confused by
pseudo-tags.
IOW, the syntactical issue has come up, but it was always because the
syntax confused certain tools -- never, to my recollection that it
confused people. I reason that if that had been an issue, this would
have also come out in such conversations. It never did.
But, you don't really have to take my word for this, Chad. Nor should
you -- at least, if this still is a major concern of yours wrt
FreeMarker. If you are at IBM and have web page designers on staff, see
if you can have one or more of them work with FreeMarker on a pilot
project for a certain period of time and see whether there really is a
problem of people confusing FreeMarker directives with HTML or XML tags.
I will re-iterate that FreeMarker tags all start with quite distinctive
character sequences:
<#
and
<@
that are not valid XML/HTML anyway. These patterns can be syntax
highlighted in a separate color. (And of course, they should be.)
Now, if there is real solid evidence that this is a genuine problem,
that people still get all dazed and confused because they can't
distinguish a FM directive from an HTML tag, like *even* if you
syntax-highlight HTML tags in orange and FTL in purple, I will be very
interested in hearing about this.
But, really, you must understand that, until then, given the data that I
have on this question, it just does not seem like a fruitful line of
inquiry or discussion. It seems utterly sterile because it simply does
not appear that this is a real-world problem.
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
> Chad.
>
>
>
> Austin Taylor <au...@gmail.com>
> 10/08/2005 05:14 PM
> Please respond to
> "Velocity Users List"
>
>
> To
> Velocity Users List <ve...@jakarta.apache.org>
> cc
>
> Subject
> Re: [ANN] Viento - WHY?
>
>
>
>
>
>
> Jonathan, you really are coming across as polemic. Try to be more
> contemplative (like maybe you actually considered the other person's point
> of view) than defensive.
>
> Well, in other contexts, such things have been deemed to be an
>
>>advantage. Java syntax was based on that of C to make it more palatable
>>to all the existing C hackers. Java, in fact, looks like C but is not C.
>>
>>Most people would guess that this strategy did work, in fact. So, why is
>>this case so different? If FTL looks like HTML but is not HTML, why does
>>this lead HTML hackers to reject it, yet when Java looks like C but is
>>not C this would tend to enhance Java's acceptability?
>
>
>
> That's a very interesting point. I suppose, for HTML people, FreeMarker's
> syntax might be great. As a programmer, I prefer something that feels more
> like a 'real' programming language. The syntax in Viento is designed to be
> like Java, with a little sugar from Ruby to make it worthwhile, and a few
> $
> from perl to make it a template language.
>
> Austin
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Chad Meadows <cm...@us.ibm.com>.
The analogy is not accurate. If Java was written by interweaving it
within a C program this would be an accurate analogy. In which case, I
would suspect everyone would then consider that a syntax nightmare.
Chad.
Austin Taylor <au...@gmail.com>
10/08/2005 05:14 PM
Please respond to
"Velocity Users List"
To
Velocity Users List <ve...@jakarta.apache.org>
cc
Subject
Re: [ANN] Viento - WHY?
Jonathan, you really are coming across as polemic. Try to be more
contemplative (like maybe you actually considered the other person's point
of view) than defensive.
Well, in other contexts, such things have been deemed to be an
> advantage. Java syntax was based on that of C to make it more palatable
> to all the existing C hackers. Java, in fact, looks like C but is not C.
>
> Most people would guess that this strategy did work, in fact. So, why is
> this case so different? If FTL looks like HTML but is not HTML, why does
> this lead HTML hackers to reject it, yet when Java looks like C but is
> not C this would tend to enhance Java's acceptability?
That's a very interesting point. I suppose, for HTML people, FreeMarker's
syntax might be great. As a programmer, I prefer something that feels more
like a 'real' programming language. The syntax in Viento is designed to be
like Java, with a little sugar from Ruby to make it worthwhile, and a few
$
from perl to make it a template language.
Austin
Re: [ANN] Viento - WHY?
Posted by Austin Taylor <au...@gmail.com>.
Jonathan, you really are coming across as polemic. Try to be more
contemplative (like maybe you actually considered the other person's point
of view) than defensive.
Well, in other contexts, such things have been deemed to be an
> advantage. Java syntax was based on that of C to make it more palatable
> to all the existing C hackers. Java, in fact, looks like C but is not C.
>
> Most people would guess that this strategy did work, in fact. So, why is
> this case so different? If FTL looks like HTML but is not HTML, why does
> this lead HTML hackers to reject it, yet when Java looks like C but is
> not C this would tend to enhance Java's acceptability?
That's a very interesting point. I suppose, for HTML people, FreeMarker's
syntax might be great. As a programmer, I prefer something that feels more
like a 'real' programming language. The syntax in Viento is designed to be
like Java, with a little sugar from Ruby to make it worthwhile, and a few $
from perl to make it a template language.
Austin
Re: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Chad Meadows wrote:
> I simply don't quite understand what seems to be a pushback to
> acknowledging there is a community of people who do not like the syntax.
Well, I'm sorry that you are perceiving things this way. However, I do
not think it reflects reality. I will start by saying that I and the
rest of the FreeMarker developers are clearly far more responsive to
user feedback than the Velocity people are. (That's not even saying
hardly anything, frankly.) Now, I'm biased obviously, but I don't think
this can be legitimately debated. Not only are we more responsive to
feedback from our own users, but historically, we have been more
responsive to feedback from Velocity users than Velocity developers have
been(!) I say this completely seriously. Various features added to
FreeMarker over the last several years originate in ideas proposed on
this list.
But there is feedback and there is feedback. Some things are going to be
taken more seriously than other things. The most useful feedback is that
which comes from people who are using FreeMarker to do some non-trivial
work and hit problems and limitations. Feedback from people who have
never used our tool in any serious way, and is of the nature of: "I
think the templates aren't really pretty." cannot be classed in the same
category.
Such feedback is, after all, of an utterly subjective, airy-fairy
nature, since such aesthetic matters, that one template syntax is
prettier than another, are essentially arbitrary. And meanwhile, we have
feedback from people using FreeMarker to do serious work that indicates
that they find the syntax preferable. I earlier pointed to this blog
entry as a case in point:
http://blog.nominet.org.uk/tech/Web/2005/06/29/Switching+from+Velocity+to+FreeMarker.html
Meanwhile, we're talking about a project that is quite well established
in its space with a very large number (I have no idea precisely how big)
of existing templates being used in production and so on.
At this stage in the history of the project, can we radically transform
our template language syntax? Should we do so on the basis of feedback
that comes from people who have never even used the tool? Meanwhile, we
are not even talking about it being broken in any actual way, I mean,
change the syntax for purely aesthetic reasons, at this stage in the
project's history...
Put yourself in my position Chad. Is this really useful feedback of a
sort that I can really act on?
I can assure you, that the day you provide feedback that I feel I can
leverage to make FreeMarker better, you will see me react quite differently.
> I
> have shown the syntax of velocity side by side with freemarker among those
> who had never seen either. Velocity was preferred.
Well, again, put yourself in my position, Chad. How seriously would you
take feedback of this nature if you were in my shoes? I believe that the
answer, if you are honest with yourself, is that you could not take it
particularly seriously.
Just for starteres, we're talking about people who have never used
either tool to do any serious work, being asked to formulate an opinion
about something on the most absolutely flimsy grounds. But also, there
is a deeper problem with the feedback in question.
I could not help but notice that you are writing me from an ibm.com
domain. IBM is a very large hierarchical organization. (Correct me if
I'm wrong.) People who operate in those environments are conditioned to
tell people what they want to hear. This, particularly, when the people
in question are perceived to have higher status and power than they do.
(Again, correct me if I'm wrong.)
Now, I don't mean that java hackers have that much status and power in
the organization, but more status than web developers, surely (who have
more status than the cleaning staff, I presume). If, at any point, you
had tipped your hand that you had some existing preference for velocity,
there could easily be a strong tendency for people just to agree with
you that velocity was "nicer" in some superficial way. To tell people
what you think they want to hear is the path of least resistance in
large organizations.
For me, this is one plausible explanation. I wasn't there and thus, do
not know the context. But really, it is easier for me to believe this
than to believe that people who had never seen either of:
<#if user.isLoggedIn>
or
#if ($user.isLoggedIn)
before in their entire lives would really, deep down, give a ****. On
what basis would a lay person have any significant preference for one
over the other? A priori, it is quite surprising. It seems entirely
possible that you tipped things (probably unconsciously) by letting them
know that you had an existing preference for Velocity.
You know, in medical research, when you test a new drug, you always give
the control group a placebo, a do-nothing pill, except this group does
not know that the pill does nothing. You see, people might have some
tendency to report an improvement in their symptoms simply because they
were taking a pill, which is presumed to do something (whether it does
or not) so you give the control group a do-nothing pill, the placebo, in
order to factor that effect out.
What I mean is that, whether the syntax issue is really that significant
is an empirical question that could be resolved empirically, but you
would need a properly constructed experiment. Also, there is the issue
of sufficient sample size. I mean, you ask 1 or 2 or 3 guys who say they
think Velocity templates "look nicer" and I am supposed to draw strong
conclusions from this.
Moreover, you are expressing some surprise (even with some slight
undertone of indignation) that I am not very swayed by this. How would
you react in my shoes?
> General responses to
> freemarker, "it looks more cryptic. it looks like xml, but is not xml.".
Well, in other contexts, such things have been deemed to be an
advantage. Java syntax was based on that of C to make it more palatable
to all the existing C hackers. Java, in fact, looks like C but is not C.
Most people would guess that this strategy did work, in fact. So, why is
this case so different? If FTL looks like HTML but is not HTML, why does
this lead HTML hackers to reject it, yet when Java looks like C but is
not C this would tend to enhance Java's acceptability?
Have you thought about that? You see, again, put yourself in my shoes.
What am I to make of this?
> Make of it what you will, that is feedback I have received. You are the
> designers, it seems intuitive to you. Apparently it is not for everyone.
> Would it be valuable for people to push past what may seem to them to be
> an awkward syntax? Yes, certainly, freemarker is very powerful and so are
> regular expressions. But there are people who are intimidated by syntax
> that does not feel natural. There were a number of people in this thread
> that mentioned the simplistic appearance of the velocity syntax was
> important in their decision. Should we accuse them all of not knowing how
> to use editors and tools for syntax highlighting?
Accuse? I would no more accuse somebody of not knowing how to use syntax
highlighting in an editor than I would accuse them of not knowing what
the capital of Outer Mongolia is. If somebody doesn't know something,
they don't know it. I did not emerge from the womb knowing how to
configure text editors. (Or anything else...)
Or maybe they knew about syntax highlighting in the context of editing
java or C source code, but it never occured to them to apply the same
thing to editing the templates. Not an accusation. Sometimes ideas that
are obvious in retrospect take a while to occur to me.
But if I know something and somebody else doesn't, there is a simple
solution to that. I can share my knowledge. That's what these kinds of
forums about in principle.
A problem emerges if I keep telling somebody something and then they
still keep bringing up the same point, as if they still don't know
whatever the thing is. The, obviously, I may start to suspect that the
people in question are being deliberately obtuse.
Have you ever found yourself in such situations, Chad? How should one react?
> or maybe this is
> valuable input into how freemarker might evolve into something that an
> even greater community will be enthused about. It is up to you to decide
> how to use what I perceive as valuable feedback from potential users.
Well, I guess we differ here. I do not perceive the feedback in question
as particularly valuable. That is not intended to be insulting. Really.
It is simply that it is not valuable because I see no way of extracting
any value from it.
I really hope I have clarified some of these issues for you, Chad.
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
> Chad.
>
>
>
> Jonathan Revusky <re...@wanadoo.es>
> Sent by: news <ne...@sea.gmane.org>
> 10/07/2005 04:02 PM
> Please respond to
> "Velocity Users List"
>
>
> To
> velocity-user@jakarta.apache.org
> cc
>
> Subject
> Re: [ANN] Viento - WHY?
>
>
>
>
>
>
> Chad Meadows wrote:
>
>>Yes, it is mainly for the reasons you already stated, plus just on a
>>visual level the freeMarker tags don't stand out as well.
>
>
> Chad, you have heard of syntax highlighting, right? I certainly wouldn't
> want to edit code of any sort -- C, python, java, freemarker, whatever
> -- in an editor that lacked this feature. All the freemarker directives
> use a clearly recognizable (particularly via regexp) pattern <#...> for
> the built-in directives and <@....> for user-defined ones. So most any
> editing tool can be configured to have these things stand out.
>
> So, if freemarker directives are blue, let's say, and HTML tags are
> green, is that standing out well enough for you? (If it's not, use bold
> vs. italic as well....) People have donated syntax highlighting
> configuration files for various editing environments already, but in any
> case, they wouldn't be that hard to set up in general.
>
> So, is this complaint, that FTL directives do not "stand out"
> sufficientlhy being made in completely good faith, or is it that people
> are this lazy about setting up their editing environments (or those of
> other people) so as to be maximally productive?
>
>
>
>> Especially to
>>people who are not exactly the most XML savvy.
>
>
> Hmm, well, I'm not sure I see your point. Web designers would be quite
> savvy about markup-based code. I would certainly hope that any web
> designer I would hire knows HTML far better than *I* do. I try to avoid
> HTML frankly.
>
> Do you seriously think that a web designer will think that <#if
> user.isLoggedIn> is a regular HTML tag? Even if they do initially
> operate under that misconception, how long would it take of using
> FreeMarker in their daily work to get this straight?
>
> But particularly with syntax highlighting showing HTML or XML tags in a
> different color from the FTL directives...
>
>
>>I think it is more of a
>>first impression thing that sometimes is hard to get over. Seems to
>>create some confusion among some people who look at the tags as they
>
> look
>
>>kinda like xml, but they are not xml.
>
>
> Well, at least, in the early days, when I first started using
> FreeMarker, like around late 1999, I thought that the syntax was a win,
> simply because you could introduce it (via a white lie) as a new kind of
> tag that did certain "stuff". Of course, it's not really that. That's a
> sort of useful little white lie(*) to help people get going with
> something.
>
> Overall, I do not get the sense that the syntactical issue is anything
> like a first-order thing. Probably, if we performed the conceptual
> experiment that Velocity had FreeMarker's syntax and vice versa, the
> very same people would still be proclaiming that it was FM's syntax that
> turns them off of it and that Velocity's was so clean. People just tend
> to get used to certain things and then become overly devoted or
> religious about them.
>
>
>
>
>>[ and ] seems like a reasonable alternative to me.
>
>
> That's already available in our CVS trunk.
>
> But anyway, while one hears people saying that they are sticking with
> Velocity because of its syntax, I know of no case (it has not come to my
> attention anyway) of anybody switching from FreeMarker to Velocity for
> the syntax. Actually, I can't think of any cases of people switching
> from FreeMarker to Velocity. I pointed out blog entries of people
> detailing their experience going from FM->Vel. I don't know of any
> similar blog entries detailing a migration the other way round.
>
> Regards,
>
> Jonathan Revusky
>
> (*) I do hope nobody will use this as proof that I am a liar. :-)
>
>
>>Thanks,
>>
>>Chad.
>>
>>
>>
>>
>>Daniel Dekany <dd...@freemail.hu>
>>10/07/2005 01:34 PM
>>Please respond to
>>"Velocity Users List"
>>
>>
>>To
>>"Velocity Users List" <ve...@jakarta.apache.org>
>>cc
>>
>>Subject
>>Re: [ANN] Viento - WHY?
>>
>>
>>
>>
>>
>>
>>Friday, October 7, 2005, 7:14:41 PM, Chad Meadows wrote:
>>
>>
>>
>>>Hi Jonathan,
>>>
>>>"In any case, if the only reason was the syntax, say, and the semantics
>>>and capabilities of FreeMarker were satisfactory, why not just tweak
>>>FreeMarker's javacc grammar to use different delimiters that you like
>>>better?"
>>>
>>>Do you have a FAQ or something on FreeMarker which describes this for us
>>>who are not familiar with javacc. The syntax issue has been the primary
>>>reason that has kept many users away from FreeMarker in my area as well.
>>
>>
>>What exactly was their problem with the syntax?
>>
>>
>>
>>>Just from the sample of emails on this list it would seem this is a very
>>>important issue. Some guidance on how to tweak the delimeters may prove
>>>to be very valuable.
>>
>>
>>It seems that very soon you can chose between using < and > or [ and ].
>>It will be added because many users has reported that he has problems
>>because the interferences with the HTML/XML syntax (that < and > are
>>reserved in them) confuses certain tools.
>>
>>
>>
>>>Thanks,
>>>Chad.
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Chad Meadows wrote:
> Hi Daniel,
> I think [#..] is pretty good improvement. There should be less tool
> complaints as well I think it is a bit easier on the eyes IMHO.
Well, if you want a freemarker.jar that allows this syntax, I can email
it to you. It will be in a release with a couple of weeks at most, I'd
say. But if you're eager to actually try it...
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax?
Posted by Chad Meadows <cm...@us.ibm.com>.
Hi Daniel,
I think [#..] is pretty good improvement. There should be less tool
complaints as well I think it is a bit easier on the eyes IMHO.
Thanks,
Chad.
Daniel Dekany <dd...@freemail.hu>
10/08/2005 06:37 PM
Please respond to
"Velocity Users List"
To
"Velocity Users List" <ve...@jakarta.apache.org>
cc
Subject
Re: What's the ideal syntax?
Saturday, October 8, 2005, 3:49:41 PM, Chad Meadows wrote:
> Hi Daniel,
>
> This is what I think might be favorable, at least for me. The ${..}
> syntax has become somewhat popular as script substituion in several
> contexts such as JSTL, ANT, Jelly etc. For that reason I actually would
> prefer all variables in the form ${foo} etc. I like consistency. So I
> want to look at some file and easily identify which parts are dynamic or
> part of the template script. Therefore, out of the list of delimeters
you
> mentioned. I actually like #{template directive...} since it has a
> resemblance to the variable substitution.
Maybe... just it resembles to a variable substitution a bit too much.
And where it really starts to look confusing is template languages where
there are multiple type of interpolations (like JSP 2.1 have ${...} and
#{...}). So on those cases I'm maybe rather on [#...]. Well, subjective
question enough anyway...
> It looks more consistent. I think this will feel much more natural to
> those who have been exposed to script in these other contexts. For
> those who have never seen any script, I believe it also has more of a
> visual distinction from xml/html elements as well.
>
> I as well am not sure if it can be greatly simplified beyond that and
> maybe it does not need to be. It is always the case that sometimes
> flexibility comes with some complexity. It is not necessarily that
anyone
> I have shown FreeMarker actually discarded it as an option just because
of
> the syntax. The syntax is just an inhibitor when at first glance a need
> for any of the advanced functions of FreeMarker may not have been in the
> requirements. When projects are pushed to the limit on schedules,
> adopting what get's the job done with lowest learning curve is often the
> choice.
You don't have to learn all features of FreeMarker... they are waiting
there if you need them. And then you will like that they are there.
Otherwise I don't think writing simple templates is more complicated
than with Velocity. And actually, in the case where you learn the extra
features, you had to learn using a tool in Velocity... at least the
"extra features" are documented on a single place and are always
available.
> Thanks,
> Chad.
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax?
Posted by Daniel Dekany <dd...@freemail.hu>.
Saturday, October 8, 2005, 3:49:41 PM, Chad Meadows wrote:
> Hi Daniel,
>
> This is what I think might be favorable, at least for me. The ${..}
> syntax has become somewhat popular as script substituion in several
> contexts such as JSTL, ANT, Jelly etc. For that reason I actually would
> prefer all variables in the form ${foo} etc. I like consistency. So I
> want to look at some file and easily identify which parts are dynamic or
> part of the template script. Therefore, out of the list of delimeters you
> mentioned. I actually like #{template directive...} since it has a
> resemblance to the variable substitution.
Maybe... just it resembles to a variable substitution a bit too much.
And where it really starts to look confusing is template languages where
there are multiple type of interpolations (like JSP 2.1 have ${...} and
#{...}). So on those cases I'm maybe rather on [#...]. Well, subjective
question enough anyway...
> It looks more consistent. I think this will feel much more natural to
> those who have been exposed to script in these other contexts. For
> those who have never seen any script, I believe it also has more of a
> visual distinction from xml/html elements as well.
>
> I as well am not sure if it can be greatly simplified beyond that and
> maybe it does not need to be. It is always the case that sometimes
> flexibility comes with some complexity. It is not necessarily that anyone
> I have shown FreeMarker actually discarded it as an option just because of
> the syntax. The syntax is just an inhibitor when at first glance a need
> for any of the advanced functions of FreeMarker may not have been in the
> requirements. When projects are pushed to the limit on schedules,
> adopting what get's the job done with lowest learning curve is often the
> choice.
You don't have to learn all features of FreeMarker... they are waiting
there if you need them. And then you will like that they are there.
Otherwise I don't think writing simple templates is more complicated
than with Velocity. And actually, in the case where you learn the extra
features, you had to learn using a tool in Velocity... at least the
"extra features" are documented on a single place and are always
available.
> Thanks,
> Chad.
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Henning P. Schmiedehausen wrote:
> Jason Pettiss <ja...@TheCatalis.com> writes:
>
>
>>popular choice. Just like Britney Spears. Except Britney Spears isn't
>
>
> I hereby invoke the variant of Godwin's law that includes Britney
> Spears.
>
> Now seriously folks: What does Britney Spears has in common with
> Velocity? If you want to do advocacy, do it somewhere else.
>
> Best regards
> Henning
>
What was Jason advocating there? Young ladies with large breasts?
Odd. That doesn't seem like something that needs a lot of advocacy.
Jonathan Revusky
--
freemarker project, http://freemarker.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Jason Pettiss <ja...@TheCatalis.com> writes:
>popular choice. Just like Britney Spears. Except Britney Spears isn't
I hereby invoke the variant of Godwin's law that includes Britney
Spears.
Now seriously folks: What does Britney Spears has in common with
Velocity? If you want to do advocacy, do it somewhere else.
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Jason Pettiss <ja...@TheCatalis.com>.
No choice? But what about Applets, Flash, XWT, SVG? XML or PDF or hell
even postscript? If it's so bad why didn't all the engineers rise up
and adopt a "better" standard, and all the end users around the world
throw us a parade in celebration? HTML sucks from my point of view, as
I write very thick looking thin clients. Dynamic web sites are NOT the
documents of scrolling content with a few black and white pictures
envisioned by Berners-Lee...
We deal with it not because there's no choice, but because it's the
popular choice. Just like Britney Spears. Except Britney Spears isn't
a psuedo-standard that engineers are forced to dirty their hands on
(teehee).
Death isn't chosen, so bad example.
Taxes are, though! And given the taxing conventions chosen by free and
democratic nations and states-- yes, you would have to conclude that
taxes are "popular" in at least one sense. However not "popular" like
Britney Spears. Perhaps "popular" like HTML... ah sigh, the fun you can
have when you question what the definition of "is" is. ;-)
Instead of "popular" let's use "prevalent". HTML is prevalent because
your average Joe can use it and get his job done. So can a developer
for that matter, albeit with some minor cussing along the way.
--jason
Jonathan Revusky wrote:
> Daniel Dekany wrote:
>
>> Saturday, October 8, 2005, 10:43:57 PM, Jason Pettiss wrote:
>>
>>
>>> Take HTML as the ultimate liberal markup language and then look at its
>>> popularity with the general public.
>>
>>
>>
>> Of course it is 100% popular since people had no choice.
>
>
> <LOL>
>
> You beat me too it, Daniel. I was going to make the same point.
>
> Of course, if the fact that we all deal with HTML because there is no
> choice is not the same thing as it being "popular". At least I don't
> think so.
>
> If that were the case, the most "popular" things would be death and
> taxes. Rather odd use of the word "popular" ... :-)
>
> Cheers,
>
> Jonathan Revusky
> --
> freemarker project, http://freemarker.org/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Daniel Dekany wrote:
> Saturday, October 8, 2005, 10:43:57 PM, Jason Pettiss wrote:
>
>
>>Take HTML as the ultimate liberal markup language and then look at its
>>popularity with the general public.
>
>
> Of course it is 100% popular since people had no choice.
<LOL>
You beat me too it, Daniel. I was going to make the same point.
Of course, if the fact that we all deal with HTML because there is no
choice is not the same thing as it being "popular". At least I don't
think so.
If that were the case, the most "popular" things would be death and
taxes. Rather odd use of the word "popular" ... :-)
Cheers,
Jonathan Revusky
--
freemarker project, http://freemarker.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Daniel Dekany <dd...@freemail.hu>.
Sunday, October 9, 2005, 5:47:47 AM, Jason Pettiss wrote:
> Actually there were plenty of choices developed over the years.
That meant to sulfil the role of HTML? What? BTW, when something is so
widely adopted than HTML, it will be very hard for another technology to
replace it. The initial resistance is just too high, because HTML is
already everywhere and known be a lot of people. Also, for HTML there
are dozens of tools available.
Anyway, my point is not that HTML is bad or not, but that technologies
are often not winning because of technical superiority, but because of
marketing and other "political" thing. So that something is widely
adopted doesn't mean that it was the best technology or that it is good
at all.
> Remember, HTML is just a subset variant of SGML,
(To be precise, it's not. It's an SGML application. XML is a subset of
SGML.)
> which itself is just an
> arbitrary markup format. XML is also a subset of that. But what's
> peculiar about HTML from every other markup format up to that point
> (early 90's we're talking here) is that HTML was and is incredibly lax
> in its rules. None of the others were. This was new. And HTML took
> off rapidly.
I guess the lax rules come from how the first popular browsers has
implemented HTML... it was the decision of the authors of those
browsers, right? Because according the "standard" HTML rules are not
lax. So when those browser (Mosaic, early Netscape? I don't know) become
widespread, then HTML rules become lax in practice... but again, then it
was most certainly just the decision of few programmer guys.
BTW, I have noticed that the browsers that support XHTML
(Mozilla/FireFox and Opera; IE doesn't support real XHTML, not even the
incoming IE7) just show an error page if an XHTML is not well-formed
(note that they will not handle XHTML as that if you serve it as
text/html). However, they don't care of validity (isn't it silly?).
> Javascript hasn't always been around, and many other scripting languages
> preceded it. (Think of all the microsoft variants, for example, which
> are still as -- dislikable -- as always.) But Javascript is the one
> that really took off with the general public. And the most insanely
> lax-- to the point of being broken some might say...
>
> You are absolutely right. Popular was indeed a bad word choice. Perhaps
> I meant "widely accepted", or "used by the masses". I certainly didn't
> mean "good" or "beautiful"... the technological winners throughout
> history have very rarely been the ones the engineers would pick.
> They're just the best compromise between competing interests, which
> generally makes them "ugly" solutions in the eyes of an engineer.
>
> Rail against it if you wish, but the types of people working with
> content will decreasingly be technical in nature, as template technology
> becomes better. As time goes on you will increasingly have to support
> the needs of, well as you say it, the obese, stupid, psycho types.
Well people often like things that actually make life more difficult for
them.
> Don't think that they're going to bend over backwards to understand the
> intricacies of meta-syntax or the difference between a semicolon and a
> comma to a computer program-- they're not.
>
> They'll simply choose a technology which doesn't require that of them,
> unaware of the hidden dangers of such a shallow choice...
Sure, life is hard...
But anyway, they are not always in the position to choose... :)
>
> --jason
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Jason Pettiss <ja...@TheCatalis.com>.
Actually there were plenty of choices developed over the years.
Remember, HTML is just a subset variant of SGML, which itself is just an
arbitrary markup format. XML is also a subset of that. But what's
peculiar about HTML from every other markup format up to that point
(early 90's we're talking here) is that HTML was and is incredibly lax
in its rules. None of the others were. This was new. And HTML took
off rapidly.
Javascript hasn't always been around, and many other scripting languages
preceded it. (Think of all the microsoft variants, for example, which
are still as -- dislikable -- as always.) But Javascript is the one
that really took off with the general public. And the most insanely
lax-- to the point of being broken some might say...
You are absolutely right. Popular was indeed a bad word choice. Perhaps
I meant "widely accepted", or "used by the masses". I certainly didn't
mean "good" or "beautiful"... the technological winners throughout
history have very rarely been the ones the engineers would pick.
They're just the best compromise between competing interests, which
generally makes them "ugly" solutions in the eyes of an engineer.
Rail against it if you wish, but the types of people working with
content will decreasingly be technical in nature, as template technology
becomes better. As time goes on you will increasingly have to support
the needs of, well as you say it, the obese, stupid, psycho types.
Don't think that they're going to bend over backwards to understand the
intricacies of meta-syntax or the difference between a semicolon and a
comma to a computer program-- they're not.
They'll simply choose a technology which doesn't require that of them,
unaware of the hidden dangers of such a shallow choice...
--jason
Daniel Dekany wrote:
>Saturday, October 8, 2005, 10:43:57 PM, Jason Pettiss wrote:
>
>
>
>>Take HTML as the ultimate liberal markup language and then look at its
>>popularity with the general public.
>>
>>
>
>Of course it is 100% popular since people had no choice. A lot of people
>needs to create web pages, and they practically must use HTML, and all
>the broken browsers. (And is it good that most of the HTML-s on the net
>are broken? In general, can we call the state of Web design world good?
>No, it's really a big chaos...)
>
>And again:
>
> popular != good
>
>It's like most people like to eat a lot, and then they will be fat like
>pigs and sick and everything. So although eating a lot is popular, you
>still wouldn't recommend it to your loved ones, right?
>
>
>
>>You often don't need to close your elements, casing doesn't matter,
>>invalid content is quietly ignored, and you can even bungle the
>>
>>
>
>And after learning from all of this, what is the direction of the IT
>world? XML, XHTML. I.e. you must explicitly close all elements, and case
>does mater. And I think browser will become more draconic too, at least
>as far as they get XHTML with the proper MIME type.
>
>
>
>>nesting and most browsers will display everything close to what the
>>user intended. Very popular, user friendly.
>>
>>
>
>I think these are false friends... People like to sweep under the carpet
>as I said, but they eventually just lose with that, on the long run at
>least. Just they don't recognize it. Again, it's like you will like the
>people who don't tell you anything negative (because they are polite and
>like).
>
>
>
>>A total headache for the
>>browser engineer. You want an example of a liberal programming
>>language this is incredibly popular and usable by non-programmers?
>>Javascript.
>>
>>I mean I hear you-- debugging these things and *proving* they are
>>correct is difficult, sometimes impossible. Fortunately if you've got a
>>language that's usable with little skill and a lot of trial and error--
>>no big fat error messages, no explosions, no need to check logs or
>>understand parser error messages or count line numbers-- then you the
>>developer have just saved yourself a LOT of boring monkey work. Because
>>you can hire monkeys to do it for you. And the more the monkeys can
>>figure it out by just banging away on the keyboard, the less you get
>>interrupted from the FUN stuff-- "real" coding with "real" languages
>>that DO blow up in your face and demand perfection from you.
>>
>>
>
>You think the template authors will solve the problems alone, if instead
>of getting error messages they get whatever arbitrary behavior. I think
>rather the opposite is true. Well, yes, assuming that the error messages
>are helpful and are displayed right in the browser window, but this can
>be expected from any serious template engine.
>
>
>
>>Most people psychologically can't deal with compiler errors. They need
>>to see constant forward motion, or they get discouraged. They see a
>>page, with colors, pretty pictures, and a few stray $userName's,
>>they're happy. They go fix those, and they see less stray $fooBars,
>>they're happy. If any time they have things wrong on the page, they
>>don't see their page-- instead they see a dry listing of errors...
>>no... that just doesn't fly... they get frustrated reeeeeal quick...
>>
>>
>
>Yeah, sure. People are psycho. Just, although building on the top of
>human stupidity is a winner strategy if you measure success with
>popularity, it's not necessary a good strategy if you want something
>that *works* better.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Daniel Dekany <dd...@freemail.hu>.
Saturday, October 8, 2005, 10:43:57 PM, Jason Pettiss wrote:
> Take HTML as the ultimate liberal markup language and then look at its
> popularity with the general public.
Of course it is 100% popular since people had no choice. A lot of people
needs to create web pages, and they practically must use HTML, and all
the broken browsers. (And is it good that most of the HTML-s on the net
are broken? In general, can we call the state of Web design world good?
No, it's really a big chaos...)
And again:
popular != good
It's like most people like to eat a lot, and then they will be fat like
pigs and sick and everything. So although eating a lot is popular, you
still wouldn't recommend it to your loved ones, right?
> You often don't need to close your elements, casing doesn't matter,
> invalid content is quietly ignored, and you can even bungle the
And after learning from all of this, what is the direction of the IT
world? XML, XHTML. I.e. you must explicitly close all elements, and case
does mater. And I think browser will become more draconic too, at least
as far as they get XHTML with the proper MIME type.
> nesting and most browsers will display everything close to what the
> user intended. Very popular, user friendly.
I think these are false friends... People like to sweep under the carpet
as I said, but they eventually just lose with that, on the long run at
least. Just they don't recognize it. Again, it's like you will like the
people who don't tell you anything negative (because they are polite and
like).
> A total headache for the
> browser engineer. You want an example of a liberal programming
> language this is incredibly popular and usable by non-programmers?
> Javascript.
>
> I mean I hear you-- debugging these things and *proving* they are
> correct is difficult, sometimes impossible. Fortunately if you've got a
> language that's usable with little skill and a lot of trial and error--
> no big fat error messages, no explosions, no need to check logs or
> understand parser error messages or count line numbers-- then you the
> developer have just saved yourself a LOT of boring monkey work. Because
> you can hire monkeys to do it for you. And the more the monkeys can
> figure it out by just banging away on the keyboard, the less you get
> interrupted from the FUN stuff-- "real" coding with "real" languages
> that DO blow up in your face and demand perfection from you.
You think the template authors will solve the problems alone, if instead
of getting error messages they get whatever arbitrary behavior. I think
rather the opposite is true. Well, yes, assuming that the error messages
are helpful and are displayed right in the browser window, but this can
be expected from any serious template engine.
> Most people psychologically can't deal with compiler errors. They need
> to see constant forward motion, or they get discouraged. They see a
> page, with colors, pretty pictures, and a few stray $userName's,
> they're happy. They go fix those, and they see less stray $fooBars,
> they're happy. If any time they have things wrong on the page, they
> don't see their page-- instead they see a dry listing of errors...
> no... that just doesn't fly... they get frustrated reeeeeal quick...
Yeah, sure. People are psycho. Just, although building on the top of
human stupidity is a winner strategy if you measure success with
popularity, it's not necessary a good strategy if you want something
that *works* better.
--
Best regards,
Daniel Dekany
> --jason
>
> Daniel Dekany wrote:
>
>>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
>>>
>>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Jason Pettiss <ja...@TheCatalis.com>.
Take HTML as the ultimate liberal markup language and then look at its
popularity with the general public. You often don't need to close your
elements, casing doesn't matter, invalid content is quietly ignored, and
you can even bungle the nesting and most browsers will display
everything close to what the user intended. Very popular, user
friendly. A total headache for the browser engineer. You want an
example of a liberal programming language this is incredibly popular and
usable by non-programmers? Javascript.
I mean I hear you-- debugging these things and *proving* they are
correct is difficult, sometimes impossible. Fortunately if you've got a
language that's usable with little skill and a lot of trial and error--
no big fat error messages, no explosions, no need to check logs or
understand parser error messages or count line numbers-- then you the
developer have just saved yourself a LOT of boring monkey work. Because
you can hire monkeys to do it for you. And the more the monkeys can
figure it out by just banging away on the keyboard, the less you get
interrupted from the FUN stuff-- "real" coding with "real" languages
that DO blow up in your face and demand perfection from you.
Most people psychologically can't deal with compiler errors. They need
to see constant forward motion, or they get discouraged. They see a
page, with colors, pretty pictures, and a few stray $userName's, they're
happy. They go fix those, and they see less stray $fooBars, they're
happy. If any time they have things wrong on the page, they don't see
their page-- instead they see a dry listing of errors... no... that just
doesn't fly... they get frustrated reeeeeal quick...
--jason
Daniel Dekany wrote:
>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
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Daniel Dekany <dd...@freemail.hu>.
Saturday, October 8, 2005, 4:42:10 PM, Mike Kienenberger wrote:
> Daniel Dekany wrote:
>> No template language can be too good at that... Simply, the basic idea
>> of a template languages is incompatible with strict white-space control.
>
> On the contrary, template languages are *IDEAL* for strict white-space
> control. That's the whole "template" part of template language. A
> template language is a means to specify an exact output format, and
> whitespace is part of that. Even velocity has "strict white-space
> control." It just happens to have a non-intuitive implementation.
What I'm talking about is that of course you want *easily readable*
templates, not some cryptic character soup. That's important, right?
What's the point of template engines like Velocity otherwise. So you
insert a lot of extra WS (indentation, line-break) around directives
just so the template is easy to read. The problem is, that this WS will
count as static text, in the basic case at least. With other words, your
"source code formatting" interferes with the output that you actually
meant to be printed. I have never seen a solution for this where one
could say that the WS is precisely and easily controlled. (That is, not
for general purpose (output format unaware) text template engine.)
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Spring and JTidy
Posted by Carfield Yim <ca...@carfield.com.hk>.
I've a simple method to get the output from velocity and press to
jtidy and do some validation, see if it useful to you:
public static String getHtml(final File location, final Body body,
final Context context) throws Exception {
final StringWriter writer = new StringWriter();
context.templateMan.getTemplate(context).merge(context.templateMan.getContext(context,
body, location, new TestRequest()), writer);
final ByteArrayOutputStream out = new ByteArrayOutputStream();
final Tidy tidy = new Tidy();
tidy.setXHTML(true);
tidy.parse(new ByteArrayInputStream(writer.toString().getBytes()), out);
// System.out.println(out);
return out.toString();
}
On 10/11/05, Scott Edward Skinner <ss...@cloud9.net> wrote:
> Is anyone using Velocity with Spring? What is the best way to incorporate
> JTidy? Looking over the VelocityView source, I see several places where I
> can intercept the Velocity output and send it to JTidy before passing it
> off to the response. Another possibility is to perhaps write a JTidy
> resolver and chain it to my VelocityViewResolver?
>
> -S
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Spring and JTidy
Posted by Scott Edward Skinner <ss...@cloud9.net>.
Is anyone using Velocity with Spring? What is the best way to incorporate
JTidy? Looking over the VelocityView source, I see several places where I
can intercept the Velocity output and send it to JTidy before passing it
off to the response. Another possibility is to perhaps write a JTidy
resolver and chain it to my VelocityViewResolver?
-S
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: whitespace
Posted by Jonathan Revusky <re...@wanadoo.es>.
Will Glass-Husain wrote:
> Hi,
>
> If you're genuinuely interested in where to find past discussion on this
> issue... two good resources are the project roadmap on the Wiki and the
> JIRA
Well, on the specific question I posed, the person I was addressing,
Christoph Reck, should also be a good resource. He said that this
whitespace debate had taken place and it had been resolved that it would
work the way it is described on that wiki page he pointed me too.
So, it seems like a natural question to ask when the debate occurred and
what progress has been made on this since then... Presumably, Christoph
was involved in that discussion, and thus knows when it took place.
Also, since it does seem to be a big issue for Christoph, he would also
likely be aware of what progress (if any) that had been made on
implementing this.
So it seemed reasonable to me to ask him about this. If Christoph (or
you or anybody else, for that matter) can just tell me the answer
straight away, it strikes me as a more efficient way to get the
information than, say, rooting around on 5 years worth of mailing list
archives. Even if I were going to do this, just to tell me approximately
when the discussion occurred would be helpful.
> issue tracker. The home page of JIRA allows you to see what issues have
> been completed and are scheduled for different releases. (You'll find the
> whitespace issue under 2.0).
2.0? I don't recall ever hearing about a Velocity 2.0? Is there actually
a branch that I can check out that has some beta or alpha-level
whitespace gobbling implementation? I actually would have some
professional interest in looking at this, since I am not 100% satisfied
with my own implementation of the same thing in the FreeMarker code.
Now, while I am somewhat interested in finding the answer to the
questions I posed, other people who actually use Velocity and want this
whitespace gobbling are probably far more interested than I am. I guess,
if you and Christoph, for whatever reasons, won't answer my questions, I
could go look at the resources you mentioned and report back my findings
for general edification. If you guys won't answer the question, I cannot
really see what legitimate objections you could have to this. Moreover,
it is clearly and unequivocally _on-topic_.
OTOH, maybe you should just behave in a forthright, responsible manner
and answer these things: When did the debate over the whitespace occur?
In the interim, what concrete progress has been made on this?
(Between you and me, I think that refusing to answer the question makes
you look even worse than answering it does... It starts to look like
some ludicrous variant on "taking the fifth". "I decline to answer this
question on the grounds that the answer might tend to make us look like
lamers..." :-)
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
> There's also a page dedicated to
> discussion of
> this issue in the Wiki, and about 50 messages on the velocity-dev mailing
> list debating pros and cons of different approaches. (it's not scheduled
> for version 1.5 as it does not fit the goals of 100% drop-in replacement to
> earlier versions).
>
> Best,
> WILL
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: whitespace
Posted by Will Glass-Husain <wg...@forio.com>.
Hi,
If you're genuinuely interested in where to find past discussion on this
issue... two good resources are the project roadmap on the Wiki and the JIRA
issue tracker. The home page of JIRA allows you to see what issues have
been completed and are scheduled for different releases. (You'll find the
whitespace issue under 2.0). There's also a page dedicated to discussion of
this issue in the Wiki, and about 50 messages on the velocity-dev mailing
list debating pros and cons of different approaches. (it's not scheduled
for version 1.5 as it does not fit the goals of 100% drop-in replacement to
earlier versions).
Best,
WILL
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Christoph Reck wrote:
> Hi Jonathan,
>
> since you are eager to understand how Velocity is progressing, you can
> see that Velocity is not a one-man-thing, but a team of lead developers
> and other contributors spending some of their time to test patches,
> implement requested features and to answer user questions on the
> mailing lists. One main goal seems to be the do-it-right and professionally
> (with a slower progress than in the main bread-and-butter jobs), as well
> as ensuring backward compatibility.
Though this is veering into a meta-discussion, I cannot help but make a
few comments of the "meta" nature. When I read the above at first, I was
naturally irritated. There is this level of insufferable pompous
posturing -- "we are such professionals blah blah" -- that I find to be
extremely provocative.
I initially perceived this as a form of aggression or provocation. And
then, this lead me to wonder whether the intent, in fact, was to enrage
me, and get me to say something immoderate in response. (And that, in
turn, would give the yahoo elements here something to sink their teeth
into.)
But actually, I don't think you're that Machiavellian. This kind of
empty, pathetic posturing is probably just something reflexive at this
point. It seems to be the norm in this community. Since you guys do seem
to function in your own kind of crazy bubble, I guess you don't have a
sense of just how preposterous it would seem to any outside observer. As
such, you are casting yourself in a somewhat ridiculous light, and you
might be doing yourself a favor to take that into consideration...
Anyway, all this stuff about what great professionals you are, in the
context of basic features simply not being implemented, sort of begs the
question. If the progress you are detailing about this whitespace issue
is typical of the professionalism of this project, then maybe what you
need is some unprofessionalism, then maybe you could get some things
done! :-)
>
> The fact that Velocity has a large user comunity lies on the simplyness
> and beauty of the approach. It is very useful as it is. Some enhancement
> would raise its usefullenss, and these are finding its way in, mostly
> in a BC form.
Well, Christoph, the above statements are entirely vacuous. The
_approach_ of Velocity may well be "simple" and "beautiful", but not
more so than any other template engine. The basic idea of a template
engine is, in fact, simple.
Now, Velocity may well be "simple" in the sense that it lacks many
features that a more powerful tool like FreeMarker has. However, to
suggest that people performed a duly dilligent comparison of these tools
and opted for Velocity because it is _lacking_ in various features does
not really ring true. Do you believe this?
After all, it doesn't bear close scrutiny, since, if you just use
FreeMarker in the exact same way that you would use Velocity -- not
leveraging any more advanced features -- it is not any less simple than
Velocity. Meanwhile, just look at the workarounds being proposed for
Velocity's complete failure to handle the whitespace issue. This
definitely does not make for simplicity.
Solutions involving underpowered tools for a job will typically be more
complex than those that use an appropriate tool. The horrendous
workaround for the whitespace issue that you admit that you use is just
one such case.
>
> The proposal for the whitespace gobbling for structured templates was
> made by me in 2001.
Hmm. Well, that is a while ago, seeing how 2006 is just round the
corner,...
Christoph, I cannot easily imagine that you are not at least somewhat
disappointed by the lack of progress on this. However, you do not react
in what I would consider a normal way. If you feel disappointment about
this, you seem to be quite unwilling to express it. You seem to want to
represent that this is completely normal... "we're all fine
professionals making sure to take the time to 'do it right'...."
Well, how much time is reasonable?
> The escence was finally taken up into an issue
> http://issues.apache.org/jira/browse/VELOCITY-253
> And the different approches and community requets where summarized
> in the wiki:
> http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
>
> With the scheduling features in Jira and Will having taken the lead,
> it has been scheduled for a 2.0 release when some non-BC formatting
> changes would be possible.
>
Well, isn't backward compatibility just being used here as a mantra to
rationalize the fact that nothing has been done?
If the above referenced proposal is how whitespace *should* be handled
by Velocity, even if the changes are not completely backward compatible,
is this a reason to dawdle? I mean, whatever transitional cost has to be
assumed at some point anyway, so why not bite the bullet sooner rather
than later?
Also, the value of 100% backward compatibility in new versions can be
overstated IMO. After all, a user always has a guaranteed way of having
complete backward compatibility, which is not to upgrade their existing
version. The existing version is useful as-is, as you point out above.
Moreover, anybody totally paranoid about breaking existing code will be
very slow to upgrade anyway.
> I also suggested that the parser should not gobble any whitespaces,
> and then add a postprocesor to the AST implementing the desired/configured
> gobbling schema!
This is, in fact, how I implemented it in FreeMarker. There is a routine
that walks the parse tree after parsing and does the whitespace adjustment.
What is interesting here is that, with this disposition, there is no
backward compatibility issue, since the post-processing of the AST can
be optional. In FreeMarker 2.2.x, the whitespace stripping was a toggle
you could turn on, and then in 2.3.x, it was on by default, and you had
to explicitly turn it off.
By the way, here is something that could be of interest to you. You know
how many complaints we got from users about the fact that FM (as of 2.3)
was stripping all the extraneous whitespace by default?
Zero. Zilch. Nada.
Nichts.
Though it's theoretically not backward compatible, it would seem that
nobody missed all that extra whitespace in the output anyway. So, if you
want to benefit from the experience of our community (and why shouldn't
you?) our experience suggests that the backward compatibility
implications of this are, in fact, an ersatz issue.
>
> The implementation for such a change is far from trivial, being a rework
> of the parser, and will affect BC.
Yes, the implementation is far from trivial. I would know. You do
realize that, of all the people who are involved in this thread, there
is exactly one who has implemented this whitespace behavior in code. Me.
It was a bear to implement. Of course, as I said, our community also has
the experience of whether the backward incompatibility that this entails
is a problem in practice. I think it's safe to say that it is not.
>
> It is an open community, and anyone who is interested can jump in
> and supply a patch.
>
> Personally, if someone reworks the parser to be non-whitespace-gobbling,
> I would be eager to then provide the structured template gobbling
> implementation patch!
If somebody else does X, then you'll do Y.
Okay, but on this business of professionalism, is this level of
attachment and sentimentality to tools really very professional? For
several years now, there is another tool that has the whitespace
behavior you want. Wouldn't a true "professional" just use that rather
than insist on using something that does not have the feature he clearly
needs, and, to all outward appearances, given the lack of action in 4
years or more, may *never* have the feature in question.
I asked you whether you considered it somehow improper or unfair for me
to tell people -- in the context of a thread on the subject here -- that
FreeMarker has this whitespace removal behavior as described on your
wiki. I reason that there is nothing improper or unfair about it. People
with a professional attitude would surely be grateful that I inform them
that a tool they may not have been aware of has the feature they need.
So, Christoph, do you consider it somehow improper for me to tell people
that FreeMarker has the feature in question? (If you do, I would want to
know on what grounds...)
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org
>
> :) Christoph Reck
>
>
> Jonathan Revusky wrote:
>
>> Christoph Reck wrote:
>>
>>> Hi,
>>>
>>> the whitespace issue has been debated quite a lot, and we have a
>>> consensus in this list that we will implement in the future a
>>> gobble-none and a gobble-structured form;
>>
>>
>>
>> That is interesting to hear, Christoph.
>>
>> I'm still a bit vague on the details.
>>
>> When did all this debate occur?
>>
>> What is currently the status of implementing this? Has somebody been
>> assigned ownership of the issue?
>>
>> Is there some roadmap which says approximately when a future Velocity
>> will have this? (I do not recall it being in the list of things to be
>> in 1.5.)
>>
>> <snip>
>>
>>>>
>>>> #if $(user.isAuthorized)#*
>>>> *#Hello#*
>>>> *##else#*
>>>> *#Good Bye#**
>>>> **##end
>>>
>>>
>>>
>>>
>>> that's what I'm doing sometimes now, and it's yuck to mainatin!
>>
>>
>>
>> Well, I sympathize with that, it really seems terrible to me. OTOH,
>> are you obliged to use Velocity for these purposes, company policy or
>> something?
>>
>> Because if not, obviously, obviously I know of one better alternative
>> available. (Guess which one? ;-)) But there may be others. I have not
>> done a survey of the template engine field recently.
>>
>>
>>>
>>>>
>>>> But is this reasonable?
>>>>
>>>> Again, the fact that it is possible to achieve precise control of
>>>> whitespace is not the key point. It is that you want such control
>>>> while having a reasonable, human-readable template. That is the
>>>> raison d'être of templates really.
>>>>
>>>> Okay, I guess no Revusky posting would be complete without a
>>>> FreeMarker plug. The FreeMarker solution was to introduce whitespace
>>>> trimming directives that are applied at parse-time.
>>>>
>>>> So, in FreeMarker, you could write:
>>>>
>>>> <#if user.isAuthorized>
>>>> Hello<#t>
>>>> <#else>
>>>> Good Bye<#t>
>>>> </#if>
>>>
>>>
>>>
>>>
>>> That is exactly in the line of:
>>>
>>> http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbleStructuredTemplates
>>
>>
>>
>>
>>
>> Well, except that there is an important practical difference: this is
>> the way FreeMarker actually works, has been working for the last
>> couple of years at least. Meanwhile, you are pointing to a document
>> that says: "wouldn't it be nice if Velocity worked this way?" It is a
>> significant difference in particular when somebody needs this to be
>> working today, not at some unspecified date in the future.
>>
>> Earlier, I probably infuriated people here by saying that "if you talk
>> the talk, you should walk the walk." But this issue seems like yet
>> another case in point. If, in the Velocity community, for all the talk
>> or debate, there is not the gumption to sit down and do the work of
>> implementing badly needed functionality, and if, in our community, we
>> have done the work of implementing the feature that many people need,
>> why should I refrain from telling people this when they specifically
>> query about this? Especially when many people who could benefit from
>> our work may not be aware of it?
>>
>> So, when I have said that if you guys talk the talk, you should walk
>> the walk, you do see my point, don't you?
>>
>> It seems fair to say that, at least for people who have no significant
>> investment in Velocity, if they need or may need fine control of
>> whitespace, they should look elsewhere.
>>
>> Would you disagree with that, Christoph?
>>
>> Regards,
>>
>> Jonathan Revusky
>> --
>> lead developer, FreeMarker project, http://freemarker.org/
>>
>>>
>>>
>>>>
>>>> The <#t> directives indicate that the opening and trailing
>>>> whitespace on the line is to be gobbled, i.e. it is there to make
>>>> the template human-readable. (There are also whitespace gobbling
>>>> rules that say that the if else and the closing tag, since they
>>>> occur solely on a line with no other whitespace output, gobble their
>>>> opening and closing whitespace.)
>>>> [snip]
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Christoph Reck <ap...@recks.org>.
Hi Jonathan,
since you are eager to understand how Velocity is progressing, you can
see that Velocity is not a one-man-thing, but a team of lead developers
and other contributors spending some of their time to test patches,
implement requested features and to answer user questions on the
mailing lists. One main goal seems to be the do-it-right and professionally
(with a slower progress than in the main bread-and-butter jobs), as well
as ensuring backward compatibility.
The fact that Velocity has a large user comunity lies on the simplyness
and beauty of the approach. It is very useful as it is. Some enhancement
would raise its usefullenss, and these are finding its way in, mostly
in a BC form.
The proposal for the whitespace gobbling for structured templates was
made by me in 2001. The escence was finally taken up into an issue
http://issues.apache.org/jira/browse/VELOCITY-253
And the different approches and community requets where summarized
in the wiki:
http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
With the scheduling features in Jira and Will having taken the lead,
it has been scheduled for a 2.0 release when some non-BC formatting
changes would be possible.
I also suggested that the parser should not gobble any whitespaces,
and then add a postprocesor to the AST implementing the desired/configured
gobbling schema!
The implementation for such a change is far from trivial, being a rework
of the parser, and will affect BC.
It is an open community, and anyone who is interested can jump in
and supply a patch.
Personally, if someone reworks the parser to be non-whitespace-gobbling,
I would be eager to then provide the structured template gobbling
implementation patch!
:) Christoph Reck
Jonathan Revusky wrote:
> Christoph Reck wrote:
>
>> Hi,
>>
>> the whitespace issue has been debated quite a lot, and we have a
>> consensus in this list that we will implement in the future a
>> gobble-none and a gobble-structured form;
>
>
> That is interesting to hear, Christoph.
>
> I'm still a bit vague on the details.
>
> When did all this debate occur?
>
> What is currently the status of implementing this? Has somebody been
> assigned ownership of the issue?
>
> Is there some roadmap which says approximately when a future Velocity
> will have this? (I do not recall it being in the list of things to be in
> 1.5.)
>
> <snip>
>
>>>
>>> #if $(user.isAuthorized)#*
>>> *#Hello#*
>>> *##else#*
>>> *#Good Bye#**
>>> **##end
>>
>>
>>
>> that's what I'm doing sometimes now, and it's yuck to mainatin!
>
>
> Well, I sympathize with that, it really seems terrible to me. OTOH, are
> you obliged to use Velocity for these purposes, company policy or
> something?
>
> Because if not, obviously, obviously I know of one better alternative
> available. (Guess which one? ;-)) But there may be others. I have not
> done a survey of the template engine field recently.
>
>
>>
>>>
>>> But is this reasonable?
>>>
>>> Again, the fact that it is possible to achieve precise control of
>>> whitespace is not the key point. It is that you want such control
>>> while having a reasonable, human-readable template. That is the
>>> raison d'être of templates really.
>>>
>>> Okay, I guess no Revusky posting would be complete without a
>>> FreeMarker plug. The FreeMarker solution was to introduce whitespace
>>> trimming directives that are applied at parse-time.
>>>
>>> So, in FreeMarker, you could write:
>>>
>>> <#if user.isAuthorized>
>>> Hello<#t>
>>> <#else>
>>> Good Bye<#t>
>>> </#if>
>>
>>
>>
>> That is exactly in the line of:
>>
>> http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbleStructuredTemplates
>
>
>
> Well, except that there is an important practical difference: this is
> the way FreeMarker actually works, has been working for the last couple
> of years at least. Meanwhile, you are pointing to a document that says:
> "wouldn't it be nice if Velocity worked this way?" It is a significant
> difference in particular when somebody needs this to be working today,
> not at some unspecified date in the future.
>
> Earlier, I probably infuriated people here by saying that "if you talk
> the talk, you should walk the walk." But this issue seems like yet
> another case in point. If, in the Velocity community, for all the talk
> or debate, there is not the gumption to sit down and do the work of
> implementing badly needed functionality, and if, in our community, we
> have done the work of implementing the feature that many people need,
> why should I refrain from telling people this when they specifically
> query about this? Especially when many people who could benefit from our
> work may not be aware of it?
>
> So, when I have said that if you guys talk the talk, you should walk the
> walk, you do see my point, don't you?
>
> It seems fair to say that, at least for people who have no significant
> investment in Velocity, if they need or may need fine control of
> whitespace, they should look elsewhere.
>
> Would you disagree with that, Christoph?
>
> Regards,
>
> Jonathan Revusky
> --
> lead developer, FreeMarker project, http://freemarker.org/
>
>>
>>
>>>
>>> The <#t> directives indicate that the opening and trailing whitespace
>>> on the line is to be gobbled, i.e. it is there to make the template
>>> human-readable. (There are also whitespace gobbling rules that say
>>> that the if else and the closing tag, since they occur solely on a
>>> line with no other whitespace output, gobble their opening and
>>> closing whitespace.)
>>> [snip]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Christoph Reck wrote:
> Hi,
>
> the whitespace issue has been debated quite a lot, and we have a
> consensus in this list that we will implement in the future a
> gobble-none and a gobble-structured form;
That is interesting to hear, Christoph.
I'm still a bit vague on the details.
When did all this debate occur?
What is currently the status of implementing this? Has somebody been
assigned ownership of the issue?
Is there some roadmap which says approximately when a future Velocity
will have this? (I do not recall it being in the list of things to be in
1.5.)
<snip>
>>
>> #if $(user.isAuthorized)#*
>> *#Hello#*
>> *##else#*
>> *#Good Bye#**
>> **##end
>
>
> that's what I'm doing sometimes now, and it's yuck to mainatin!
Well, I sympathize with that, it really seems terrible to me. OTOH, are
you obliged to use Velocity for these purposes, company policy or
something?
Because if not, obviously, obviously I know of one better alternative
available. (Guess which one? ;-)) But there may be others. I have not
done a survey of the template engine field recently.
>
>>
>> But is this reasonable?
>>
>> Again, the fact that it is possible to achieve precise control of
>> whitespace is not the key point. It is that you want such control
>> while having a reasonable, human-readable template. That is the raison
>> d'être of templates really.
>>
>> Okay, I guess no Revusky posting would be complete without a
>> FreeMarker plug. The FreeMarker solution was to introduce whitespace
>> trimming directives that are applied at parse-time.
>>
>> So, in FreeMarker, you could write:
>>
>> <#if user.isAuthorized>
>> Hello<#t>
>> <#else>
>> Good Bye<#t>
>> </#if>
>
>
> That is exactly in the line of:
>
> http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbleStructuredTemplates
Well, except that there is an important practical difference: this is
the way FreeMarker actually works, has been working for the last couple
of years at least. Meanwhile, you are pointing to a document that says:
"wouldn't it be nice if Velocity worked this way?" It is a significant
difference in particular when somebody needs this to be working today,
not at some unspecified date in the future.
Earlier, I probably infuriated people here by saying that "if you talk
the talk, you should walk the walk." But this issue seems like yet
another case in point. If, in the Velocity community, for all the talk
or debate, there is not the gumption to sit down and do the work of
implementing badly needed functionality, and if, in our community, we
have done the work of implementing the feature that many people need,
why should I refrain from telling people this when they specifically
query about this? Especially when many people who could benefit from our
work may not be aware of it?
So, when I have said that if you guys talk the talk, you should walk the
walk, you do see my point, don't you?
It seems fair to say that, at least for people who have no significant
investment in Velocity, if they need or may need fine control of
whitespace, they should look elsewhere.
Would you disagree with that, Christoph?
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
>
>>
>> The <#t> directives indicate that the opening and trailing whitespace
>> on the line is to be gobbled, i.e. it is there to make the template
>> human-readable. (There are also whitespace gobbling rules that say
>> that the if else and the closing tag, since they occur solely on a
>> line with no other whitespace output, gobble their opening and closing
>> whitespace.)
>> [snip]
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Christoph Reck <ap...@recks.org>.
Hi,
the whitespace issue has been debated quite a lot, and we have a
consensus in this list that we will implement in the future a
gobble-none and a gobble-structured form; latter, with your
example:
## example of all whitespace being gobbled
#if ($user.isAuthorized)
#text(Hello)
#else
#text(Good Bye)
#end
## example of whitespace preservation:
$footer
#keepIndent()#escapeHTML($address)
If anyone has a comment on this, please add it to the wiki:
http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbling
My 2cents for the velocity syntax:
- ${foo}$bar is common practice in shell scripts
- $foo.bar.baz() is the Java flavour for object properties
- and #if...#else...#end is common practice in C-preprocessors
:) Christoph
Jonathan Revusky wrote:
>[snip]
> The problem isn't that you don't have strict whitespace control. You do.
> even in Velocity probably. (Though you have to be willing to hold your
> nose.)
>
> The real problem is that you want to have strict whitespace control and
> have your templates be human-readable. In the following fragment:
>
> #if ($user.isAuthorized)
> Hello
> #else
> Good Bye
> #end
>
> there is a lot of whitespace that exists solely in order to make the
> template more human-readable: certainly, the line-break after the #if
> directive, the line break after the #else instruction, for example. They
> are almost certainly there solely for template readability.
>
> Also, it is *highly likely* that the offsets before "Hello" and "Good
> Bye" as well as the line breaks following those strings were placed
> there solely to make the raw template more readable.
>
> In the general case, how can a template engine deduce which whitespace
> is there for template readability (and thus should be ignored) and which
> whitespace really belongs in the output?
>
> It is actually a very difficult problem. In fact, at times, I have
> thought it to be intractable.
>[snip]
> The traditional workaround has been to write something like:
>
> #if $(user.isAuthorized)Hello#else#**#Good Bye#end
>
> Of course, it occurs to me that you could maybe use the above comment
> hack more liberally in order to be able to write the fragment on
> multiple lines:
>
> #if $(user.isAuthorized)#*
> *#Hello#*
> *##else#*
> *#Good Bye#**
> **##end
that's what I'm doing sometimes now, and it's yuck to mainatin!
>
> But is this reasonable?
>
> Again, the fact that it is possible to achieve precise control of
> whitespace is not the key point. It is that you want such control while
> having a reasonable, human-readable template. That is the raison d'être
> of templates really.
>
> Okay, I guess no Revusky posting would be complete without a FreeMarker
> plug. The FreeMarker solution was to introduce whitespace trimming
> directives that are applied at parse-time.
>
> So, in FreeMarker, you could write:
>
> <#if user.isAuthorized>
> Hello<#t>
> <#else>
> Good Bye<#t>
> </#if>
That is exactly in the line of:
http://wiki.apache.org/jakarta-velocity/VelocityWhitespaceGobbleStructuredTemplates
>
> The <#t> directives indicate that the opening and trailing whitespace on
> the line is to be gobbled, i.e. it is there to make the template
> human-readable. (There are also whitespace gobbling rules that say that
> the if else and the closing tag, since they occur solely on a line with
> no other whitespace output, gobble their opening and closing whitespace.)
>[snip]
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Mike Kienenberger <mk...@gmail.com>.
On 10/8/05, Jonathan Revusky <re...@wanadoo.es> wrote:
> Again, the fact that it is possible to achieve precise control of
> whitespace is not the key point. It is that you want such control while
> having a reasonable, human-readable template. That is the raison d'être
> of templates really.
In a word, No.
The reason for having templates is to generate controlled formatted output.
The "key point" is that control over whitespace is often a necessity.
A worthy subgoal might be that the template is easy to read, but
that's just a nice extra, not a key point.
I can live without the templates being easy to read. I can't live
with uncontrollable formatting.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Mike Kienenberger wrote:
> Daniel Dekany wrote:
>
>>No template language can be too good at that... Simply, the basic idea
>>of a template languages is incompatible with strict white-space control.
>
>
> On the contrary, template languages are *IDEAL* for strict white-space
> control. That's the whole "template" part of template language. A
> template language is a means to specify an exact output format, and
> whitespace is part of that. Even velocity has "strict white-space
> control." It just happens to have a non-intuitive implementation.
The problem isn't that you don't have strict whitespace control. You do.
even in Velocity probably. (Though you have to be willing to hold your
nose.)
The real problem is that you want to have strict whitespace control and
have your templates be human-readable. In the following fragment:
#if ($user.isAuthorized)
Hello
#else
Good Bye
#end
there is a lot of whitespace that exists solely in order to make the
template more human-readable: certainly, the line-break after the #if
directive, the line break after the #else instruction, for example. They
are almost certainly there solely for template readability.
Also, it is *highly likely* that the offsets before "Hello" and "Good
Bye" as well as the line breaks following those strings were placed
there solely to make the raw template more readable.
In the general case, how can a template engine deduce which whitespace
is there for template readability (and thus should be ignored) and which
whitespace really belongs in the output?
It is actually a very difficult problem. In fact, at times, I have
thought it to be intractable.
Of course, in Velocity, it's particular egregious, largely because of
the language's wonderful syntax. Let us suppose that all the extraneous
whitespace in the above fragment is just there for template readability.
You want to output Hello or Good Bye with no opening or trailing
whitespace. How do you write it? Well, I guess...
#if ($user.isAuthorized)Hello#elseGood Bye#end
Well, first of all, is this reasonable? We really want to write the
template fragment the way it is up top, right? But that doesn't give us
what we want.
But second of all, the above doesn't even work, because #elseGood causes
a parsing problem.
The traditional workaround has been to write something like:
#if $(user.isAuthorized)Hello#else#**#Good Bye#end
Of course, it occurs to me that you could maybe use the above comment
hack more liberally in order to be able to write the fragment on
multiple lines:
#if $(user.isAuthorized)#*
*#Hello#*
*##else#*
*#Good Bye#**
**##end
But is this reasonable?
Again, the fact that it is possible to achieve precise control of
whitespace is not the key point. It is that you want such control while
having a reasonable, human-readable template. That is the raison d'être
of templates really.
Okay, I guess no Revusky posting would be complete without a FreeMarker
plug. The FreeMarker solution was to introduce whitespace trimming
directives that are applied at parse-time.
So, in FreeMarker, you could write:
<#if user.isAuthorized>
Hello<#t>
<#else>
Good Bye<#t>
</#if>
The <#t> directives indicate that the opening and trailing whitespace on
the line is to be gobbled, i.e. it is there to make the template
human-readable. (There are also whitespace gobbling rules that say that
the if else and the closing tag, since they occur solely on a line with
no other whitespace output, gobble their opening and closing whitespace.)
Another solution that already existed in FreeMarker was block-oriented
whitespace trimming, that, unlike the above cases, is applied to a block
at render time.
This has at least one problem, which is that it imposes a performance
penalty -- involving buffering of intermediate output and looking ahead
to see whether there is whitespace that should be trimmed according to
whatever rules...
Maybe in the majority of cases, the penalty would not be so noticeable,
but really, should you suffer a performance penalty for writing
human-readable templates as opposed to obfuscated ones?
I don't think so. There are other reasons that it is not a fully
satisfactory solution also...
To be totally honest here, I am not fully satisfied with our whitespace
handling stuff and maybe it needs some refinements. Also, the
implementation turned out to be quite hairy (though that is hardly any
user's problem.) Still, we do address the problem and Velocity simply
ignores it. I think that anybody who does have to output formats where
strict control of whitespace is mandatory would have to be a masochist
to opt for Velocity over FreeMarker.
Regards,
Jonathan Revusky
--
Whitespace handling in FreeMarker:
http://freemarker.org/docs/dgui_misc_whitespace.html
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Mike Kienenberger <mk...@gmail.com>.
Daniel Dekany wrote:
> No template language can be too good at that... Simply, the basic idea
> of a template languages is incompatible with strict white-space control.
On the contrary, template languages are *IDEAL* for strict white-space
control. That's the whole "template" part of template language. A
template language is a means to specify an exact output format, and
whitespace is part of that. Even velocity has "strict white-space
control." It just happens to have a non-intuitive implementation.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Daniel Dekany <dd...@freemail.hu>.
Saturday, October 8, 2005, 4:29:21 PM, Robert Koberg wrote:
> Daniel Dekany wrote:
>
>> No template language can be too good at that... Simply, the basic idea
>> of a template languages is incompatible with strict white-space control.
>
> You get strict whitespace control with XSL/XML :)
I mean, with a text template engine, i.e. a template engine that deals
with raw sequences of characters. (XSLT is not a text template engine.)
> -Rob
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Robert Koberg <ro...@koberg.com>.
Jonathan Revusky wrote:
> Robert Koberg wrote:
>
>> Daniel Dekany wrote:
>>
>>> No template language can be too good at that... Simply, the basic idea
>>> of a template languages is incompatible with strict white-space control.
>>
>>
>>
>> You get strict whitespace control with XSL/XML :)
>
>
> I am pretty sure that XSL/XML has the same problems wrt whitespace that
> template languages do.
No, you have several options. In the XML source you have
xml:space="preserve".
In XSL you have:
<xsl:output indent="yes | no" .../>
<xsl:strip-space elements="*"/> <!-- *=all-elements or you could specify
exactly which elements -->
<xsl:preserve-space elements="script textarea"/>
<xsl:stylesheet xml:space="default | preserve" .../>
When outputting text you can use entities to place linebreaks, tabs,
spaces, etc. You can also use:
<xsl:text>This is a
linebreak</xsl:text>
or:
<xsl:text>This </xsl:text>
<xsl:value-of select="$variable"/>
<xsl:text> is on one line.</xsl:text>
When setting output for certain methods like HTML or XHTML it follows
the DTD/Schema rules associated.
To me, the semantics are clear. I have trouble understanding why people
find it hard to understand (but they do...).
> Oh.... I forgot something. XSLT is not really readable by mortal humans
> anyway, so maybe the point is kind of moot....
Many humans like the way XSLT reads. YMMV.
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Robert Koberg wrote:
> Daniel Dekany wrote:
>
>> No template language can be too good at that... Simply, the basic idea
>> of a template languages is incompatible with strict white-space control.
>
>
> You get strict whitespace control with XSL/XML :)
I am pretty sure that XSL/XML has the same problems wrt whitespace that
template languages do.
That when you write something in a human-readable way, it introduces
extraneous whitespace. See my response to Mike Kienenberger on this.
Oh.... I forgot something. XSLT is not really readable by mortal humans
anyway, so maybe the point is kind of moot....
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
> -Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Robert Koberg <ro...@koberg.com>.
Daniel Dekany wrote:
> No template language can be too good at that... Simply, the basic idea
> of a template languages is incompatible with strict white-space control.
You get strict whitespace control with XSL/XML :)
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Daniel Dekany <dd...@freemail.hu>.
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: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Mike Kienenberger <mk...@gmail.com>.
Sure there is.
This is handled by the Objective-C MiscMergeKit template engine by
having all variables and directives enclosed in a starting and ending
tag.
Ie, #if (x)# text #else# text #endif#
or ${if (x)} text ${else} text ${endif}
The actual starting and ending tags can at any point be changed using a
#delimiters new-left-delimiter new-closing-delimiter # directive.
Ie,
## write html template info
#delimiters {$ $} #
write shell script template info
{$delimiters # # $}
write more html template info
I haven't found it all that useful to switch delimiters in the middle of a
template, but I definitely have found it useful to switch delimiters
at the start of a file.
On 10/8/05, Jason Pettiss <ja...@thecatalis.com> 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.
>
> 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. 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.
> 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... 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.
>
> 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-- 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.
>
> 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? 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?
>
> --jason
>
> Daniel Dekany wrote:
>
> >Friday, October 7, 2005, 11:12:21 PM, Chad Meadows wrote:
> >
> >
> >
> >>I simply don't quite understand what seems to be a pushback to
> >>acknowledging there is a community of people who do not like the syntax. I
> >>have shown the syntax of velocity side by side with freemarker among those
> >>who had never seen either. Velocity was preferred.
> >>
> >>
> >[snip]
> >
> >DISCLAIMER: This will NOT be a FreeMarker advertisement. Also, I do NOT
> >like the FreeMarker syntax (but not because of it usage of cryptic
> >delimiters... there other things historically bungled in it), although I
> >surely prefer it over Velocity's.
> >
> ><meta-discussion>
> >The unimportant thing what I want to say is that Jonathan behaves
> >roughly in this case because he becomes angry when he faces exactly the
> >same case of, well, apparent lack of professional experience (read:
> >***IGNORANCE!!!***, just I don't wanted to say that :)) again and again
> >and again... the syntax stuff. (Plus, he is pissed of on Jakarta people
> >in general, so it's not the place where he will try to keep cool his
> >blood when it wants to boil.)
> ></meta-discussion>
> >
> >
> >So, what "apparent lack of professional experience" do I refer to?
> >
> >One thing is that evaluating a template language primarily based on the
> >first impression "look and feel" goodness of its syntax is, well... Even
> >evaluation a template engine primarily based on it syntax is, well...
> >(as far as the syntax is within the borders of sanity, that is). But let
> >this alone now too.
> >
> >The other thing is, that unfortunately a syntax that look simple,
> >especially one that look good for non-programmer person at the first
> >glance, always have the dark sides, that are not apparent first. But
> >later... later you will swallow them because you are already get used to
> >the basic syntax... but the point is, it turns out that the syntax is
> >not that good after all. Like, I agree that WebMacro-style syntax (like
> >Velocity's) looks friendly at the fist glance, but unfortunately it
> >turns out that this type of syntaxes has some problems, which eventually
> >fade out the advantage of first-impression natural look (I will not deal
> >with strictly VTL specific design mistakes and bugs, since those has
> >trivial fixes):
> >
> >- To show it in VTL: #else#**#blah#end. I bet most non-programmer will
> > not figure out easily that they should use that #**#, and anyway it's
> > awkward. But it could be solved as #{else}blah. Still, then the syntax
> > has already lost from its minimalism. Because, there are two ways of
> > writing the same thing, and then wouldn't be simpler if there is only
> > one way, the way that's always safely works? Anyway, especially for
> > non-programmers, the delimiting issue is something more mystical than
> > for a programmer: "Hm.... I don't want space here... will #elseblah be
> > OK? (try) Sh*t... now what to do? (phone)" (Of course, it's the kind
> > of thing that the guy will not foresee when he falls in love with Vel.
> > at the first glance.) But, if you want, let's say it's a minor issue.
> >
> >- The $foo VS ${foo} thing. The same as with #else basically.
> > Complicates things... why not just one *safe* way (it's clean for
> > everybody where's the end of the expression), which is ${foo}. Instead
> > of two ways? Much simpler, the documentation will be sorter... Yes,
> > more typing, but I think it worth it in the case of template language.
> > But, again if you want, let's say it's a minor issue.
> >
> >- BTW as a side note, with $foo you can really use "complex"
> > expressions, like ${x + 1}. With ${...} it naturally works.
> >
> >- Again $foo VS ${foo}. You have high chance that something that meant to
> > be static text will be interpreted as a reference. Like $Id: ...$
> > Not a that minor issue... And yet another catch to remember.
> >
> >- And the most important for the last... how do you call a macro with
> > body (like <my:stuff>...</my:stuff> in JSP) with this syntax? I know,
> > Vel. doesn't support it anyway, except for some built-in directives,
> > but many template language will definitely want to (like JSP,
> > FreeMarker, Viento), for good reason IMO. Now I don't go into the
> > endless variations of solutions that I tried "on paper" and then
> > thrown away, because they had too many catches, or was too verbose, or
> > look far too alien. Can anybody show me a good solution with more-less
> > WebMacro (Velocity) style? (And don't forget to count with the text
> > editors, for which a syntax highlight should be possible.)
> >
> >I have rumbled a lot about template syntaxes in the past. I really tried
> >to find out syntaxes that have a WebMacro (or Velocity) look-and-feel,
> >or just otherwise natural look if you see what I mean. (Note that not
> >supporting macros with body is not acceptable for me.) For my biggest
> >regret, I have found that at the end of the day, the simplest and most
> >reliable syntaxes, the best compromises, were are always those where
> >there are strictly required delimiters at the left and right side of the
> >directives, like <#...>, or [#...], or even <%...%>, also ${...}, or
> >#{...}, etc, i.e. not the WebMacro look-and-feel stuff at all.
> >Furthermore at least the left side delimiter should be something that
> >doesn't clash with anything that can easily occur in the static text, so
> >just [...] is not enough, you need some additional strange character
> >after the "[" (and even before the "]" if you want really text-editor
> >friendly language). Yes, these syntaxes look alien at the first glance,
> >but I believe that after that initial emotional shock (%-/ "Whaaaat?"),
> >you will be better with them. They free of ambiguities (no cookbook
> >tricks needed), they are safer (less chance of accidental clashes),
> >while their rules can still remain damn simple. And, that they are
> >necessary more verbose than WebMacro style syntaxes is a myth... they
> >are just little bit more verbose, no important difference in that.
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Jason Pettiss <ja...@TheCatalis.com>.
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.
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. 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.
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... 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.
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-- 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.
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? 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?
--jason
Daniel Dekany wrote:
>Friday, October 7, 2005, 11:12:21 PM, Chad Meadows wrote:
>
>
>
>>I simply don't quite understand what seems to be a pushback to
>>acknowledging there is a community of people who do not like the syntax. I
>>have shown the syntax of velocity side by side with freemarker among those
>>who had never seen either. Velocity was preferred.
>>
>>
>[snip]
>
>DISCLAIMER: This will NOT be a FreeMarker advertisement. Also, I do NOT
>like the FreeMarker syntax (but not because of it usage of cryptic
>delimiters... there other things historically bungled in it), although I
>surely prefer it over Velocity's.
>
><meta-discussion>
>The unimportant thing what I want to say is that Jonathan behaves
>roughly in this case because he becomes angry when he faces exactly the
>same case of, well, apparent lack of professional experience (read:
>***IGNORANCE!!!***, just I don't wanted to say that :)) again and again
>and again... the syntax stuff. (Plus, he is pissed of on Jakarta people
>in general, so it's not the place where he will try to keep cool his
>blood when it wants to boil.)
></meta-discussion>
>
>
>So, what "apparent lack of professional experience" do I refer to?
>
>One thing is that evaluating a template language primarily based on the
>first impression "look and feel" goodness of its syntax is, well... Even
>evaluation a template engine primarily based on it syntax is, well...
>(as far as the syntax is within the borders of sanity, that is). But let
>this alone now too.
>
>The other thing is, that unfortunately a syntax that look simple,
>especially one that look good for non-programmer person at the first
>glance, always have the dark sides, that are not apparent first. But
>later... later you will swallow them because you are already get used to
>the basic syntax... but the point is, it turns out that the syntax is
>not that good after all. Like, I agree that WebMacro-style syntax (like
>Velocity's) looks friendly at the fist glance, but unfortunately it
>turns out that this type of syntaxes has some problems, which eventually
>fade out the advantage of first-impression natural look (I will not deal
>with strictly VTL specific design mistakes and bugs, since those has
>trivial fixes):
>
>- To show it in VTL: #else#**#blah#end. I bet most non-programmer will
> not figure out easily that they should use that #**#, and anyway it's
> awkward. But it could be solved as #{else}blah. Still, then the syntax
> has already lost from its minimalism. Because, there are two ways of
> writing the same thing, and then wouldn't be simpler if there is only
> one way, the way that's always safely works? Anyway, especially for
> non-programmers, the delimiting issue is something more mystical than
> for a programmer: "Hm.... I don't want space here... will #elseblah be
> OK? (try) Sh*t... now what to do? (phone)" (Of course, it's the kind
> of thing that the guy will not foresee when he falls in love with Vel.
> at the first glance.) But, if you want, let's say it's a minor issue.
>
>- The $foo VS ${foo} thing. The same as with #else basically.
> Complicates things... why not just one *safe* way (it's clean for
> everybody where's the end of the expression), which is ${foo}. Instead
> of two ways? Much simpler, the documentation will be sorter... Yes,
> more typing, but I think it worth it in the case of template language.
> But, again if you want, let's say it's a minor issue.
>
>- BTW as a side note, with $foo you can really use "complex"
> expressions, like ${x + 1}. With ${...} it naturally works.
>
>- Again $foo VS ${foo}. You have high chance that something that meant to
> be static text will be interpreted as a reference. Like $Id: ...$
> Not a that minor issue... And yet another catch to remember.
>
>- And the most important for the last... how do you call a macro with
> body (like <my:stuff>...</my:stuff> in JSP) with this syntax? I know,
> Vel. doesn't support it anyway, except for some built-in directives,
> but many template language will definitely want to (like JSP,
> FreeMarker, Viento), for good reason IMO. Now I don't go into the
> endless variations of solutions that I tried "on paper" and then
> thrown away, because they had too many catches, or was too verbose, or
> look far too alien. Can anybody show me a good solution with more-less
> WebMacro (Velocity) style? (And don't forget to count with the text
> editors, for which a syntax highlight should be possible.)
>
>I have rumbled a lot about template syntaxes in the past. I really tried
>to find out syntaxes that have a WebMacro (or Velocity) look-and-feel,
>or just otherwise natural look if you see what I mean. (Note that not
>supporting macros with body is not acceptable for me.) For my biggest
>regret, I have found that at the end of the day, the simplest and most
>reliable syntaxes, the best compromises, were are always those where
>there are strictly required delimiters at the left and right side of the
>directives, like <#...>, or [#...], or even <%...%>, also ${...}, or
>#{...}, etc, i.e. not the WebMacro look-and-feel stuff at all.
>Furthermore at least the left side delimiter should be something that
>doesn't clash with anything that can easily occur in the static text, so
>just [...] is not enough, you need some additional strange character
>after the "[" (and even before the "]" if you want really text-editor
>friendly language). Yes, these syntaxes look alien at the first glance,
>but I believe that after that initial emotional shock (%-/ "Whaaaat?"),
>you will be better with them. They free of ambiguities (no cookbook
>tricks needed), they are safer (less chance of accidental clashes),
>while their rules can still remain damn simple. And, that they are
>necessary more verbose than WebMacro style syntaxes is a myth... they
>are just little bit more verbose, no important difference in that.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Austin Taylor wrote:
>>- And the most important for the last... how do you call a macro with
>>body (like <my:stuff>...</my:stuff> in JSP) with this syntax? I know,
>>Vel. doesn't support it anyway, except for some built-in directives,
>>but many template language will definitely want to (like JSP,
>>FreeMarker, Viento), for good reason IMO. Now I don't go into the
>>endless variations of solutions that I tried "on paper" and then
>>thrown away, because they had too many catches, or was too verbose, or
>>look far too alien. Can anybody show me a good solution with more-less
>>WebMacro (Velocity) style? (And don't forget to count with the text
>>editors, for which a syntax highlight should be possible.)
>
>
>
> Have you looked at the way Viento
> handles<http://opensails.org/sails/wiki/VientoBlocksAndStuff>them?
> Obviously, we're still working through the escaping implications. In
> HTML it's not a big deal, but we're also using it to generate Java code, so
> we'll need an easy way to escape } in blocks. Since artists aren't likely to
> be generating Java code, I don't think it'll cause many problems in general
> use.
>
> There's been some discussion about changing out delimiters at runtime. I'm
> fairly new to JavaCC, but is this an easy thing to do? The generated token
> manager works off a bunch of static characters (often in switch statements).
> The desired behavior would seem to require a major refactoring of the
> generated code. Before I started working on Viento, I wanted to be able to
> do just that, but once I got my head around JavaCC, it didn't seem
> worthwhile. Any help?
It's tricky, but it is possible to switch delimiters on the fly in
JavaCC. You use lexical actions which use judicious SwitchTo() calls and
massaging the token.kind field. For an example of this, look at the
FMParser.jj file in FreeMarker. in particular look at the current
version of that file in CVS, not the one in the downloadable distro.
Look at the usage of the strictSyntaxCheck() lexical action, for
example. In the current CVS version, this code allows the directive to
be written as:
<#...>
or
[#...]
depending on an internal toggle, which is altDirectiveSyntax.
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
> Austin
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Austin Taylor <au...@gmail.com>.
> - And the most important for the last... how do you call a macro with
> body (like <my:stuff>...</my:stuff> in JSP) with this syntax? I know,
> Vel. doesn't support it anyway, except for some built-in directives,
> but many template language will definitely want to (like JSP,
> FreeMarker, Viento), for good reason IMO. Now I don't go into the
> endless variations of solutions that I tried "on paper" and then
> thrown away, because they had too many catches, or was too verbose, or
> look far too alien. Can anybody show me a good solution with more-less
> WebMacro (Velocity) style? (And don't forget to count with the text
> editors, for which a syntax highlight should be possible.)
Have you looked at the way Viento
handles<http://opensails.org/sails/wiki/VientoBlocksAndStuff>them?
Obviously, we're still working through the escaping implications. In
HTML it's not a big deal, but we're also using it to generate Java code, so
we'll need an easy way to escape } in blocks. Since artists aren't likely to
be generating Java code, I don't think it'll cause many problems in general
use.
There's been some discussion about changing out delimiters at runtime. I'm
fairly new to JavaCC, but is this an easy thing to do? The generated token
manager works off a bunch of static characters (often in switch statements).
The desired behavior would seem to require a major refactoring of the
generated code. Before I started working on Viento, I wanted to be able to
do just that, but once I got my head around JavaCC, it didn't seem
worthwhile. Any help?
Austin
Re: What's the ideal syntax?
Posted by Will Glass-Husain <wg...@forio.com>.
Hi Daniel,
Thanks for the interesting comments.
The $foo vs ${foo} issue doesn't seem that important to me. There's some
issues with Velocity syntax we struggle with -- escaping of directives is a
little strange for example -- but in general I haven't found references to
be that difficult. Perhaps that's because I don't use a lot of literal '$'
in HTML.
Plenty of other templating and web languages prove that <% %> style
delimiters work fine. PHP, ASP, JSP, Perl's Template Toolkit. Jonathan's
point in an earlier email that these type of delimiters often work better
with IDE's is a good one. (Though I disagree with the assumption that
everyone uses or needs to use an IDE.) However I've tried two different
Eclipse plugins for Velocity and both seem to recognize directives fine (and
do a decent job with references).
One thing I'd like to see in Velocity is support for nested block
statements. JSP's nested tag elements have always appealed to me. For
example, DisplayTag (http://displaytag.sourceforge.net) would be hard to
implement with Velocity since it has a block tag for the table and nested
tags specifying each column.
Having said all that it's likely in Velocity we'll continue forward in ways
that are consistent with current syntax - once design choices are made it's
hard to change them without alienating existing users. But it's interesting
to consider alternatives particularly for those creating or adopting
different systems.
Best,
WILL
P.S. Incidentally, #{else} is now legal syntax in the upcoming 1.5 release.
I always hated #else#**#blah#end myself.
----- Original Message -----
From: "Daniel Dekany" <dd...@freemail.hu>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: Friday, October 07, 2005 10:05 PM
Subject: What's the ideal syntax? Was: [ANN] Viento - WHY?
> Friday, October 7, 2005, 11:12:21 PM, Chad Meadows wrote:
>
>> I simply don't quite understand what seems to be a pushback to
>> acknowledging there is a community of people who do not like the syntax.
>> I
>> have shown the syntax of velocity side by side with freemarker among
>> those
>> who had never seen either. Velocity was preferred.
> [snip]
>
> DISCLAIMER: This will NOT be a FreeMarker advertisement. Also, I do NOT
> like the FreeMarker syntax (but not because of it usage of cryptic
> delimiters... there other things historically bungled in it), although I
> surely prefer it over Velocity's.
>
> <meta-discussion>
> The unimportant thing what I want to say is that Jonathan behaves
> roughly in this case because he becomes angry when he faces exactly the
> same case of, well, apparent lack of professional experience (read:
> ***IGNORANCE!!!***, just I don't wanted to say that :)) again and again
> and again... the syntax stuff. (Plus, he is pissed of on Jakarta people
> in general, so it's not the place where he will try to keep cool his
> blood when it wants to boil.)
> </meta-discussion>
>
>
> So, what "apparent lack of professional experience" do I refer to?
>
> One thing is that evaluating a template language primarily based on the
> first impression "look and feel" goodness of its syntax is, well... Even
> evaluation a template engine primarily based on it syntax is, well...
> (as far as the syntax is within the borders of sanity, that is). But let
> this alone now too.
>
> The other thing is, that unfortunately a syntax that look simple,
> especially one that look good for non-programmer person at the first
> glance, always have the dark sides, that are not apparent first. But
> later... later you will swallow them because you are already get used to
> the basic syntax... but the point is, it turns out that the syntax is
> not that good after all. Like, I agree that WebMacro-style syntax (like
> Velocity's) looks friendly at the fist glance, but unfortunately it
> turns out that this type of syntaxes has some problems, which eventually
> fade out the advantage of first-impression natural look (I will not deal
> with strictly VTL specific design mistakes and bugs, since those has
> trivial fixes):
>
> - To show it in VTL: #else#**#blah#end. I bet most non-programmer will
> not figure out easily that they should use that #**#, and anyway it's
> awkward. But it could be solved as #{else}blah. Still, then the syntax
> has already lost from its minimalism. Because, there are two ways of
> writing the same thing, and then wouldn't be simpler if there is only
> one way, the way that's always safely works? Anyway, especially for
> non-programmers, the delimiting issue is something more mystical than
> for a programmer: "Hm.... I don't want space here... will #elseblah be
> OK? (try) Sh*t... now what to do? (phone)" (Of course, it's the kind
> of thing that the guy will not foresee when he falls in love with Vel.
> at the first glance.) But, if you want, let's say it's a minor issue.
>
> - The $foo VS ${foo} thing. The same as with #else basically.
> Complicates things... why not just one *safe* way (it's clean for
> everybody where's the end of the expression), which is ${foo}. Instead
> of two ways? Much simpler, the documentation will be sorter... Yes,
> more typing, but I think it worth it in the case of template language.
> But, again if you want, let's say it's a minor issue.
>
> - BTW as a side note, with $foo you can really use "complex"
> expressions, like ${x + 1}. With ${...} it naturally works.
>
> - Again $foo VS ${foo}. You have high chance that something that meant to
> be static text will be interpreted as a reference. Like $Id: ...$
> Not a that minor issue... And yet another catch to remember.
>
> - And the most important for the last... how do you call a macro with
> body (like <my:stuff>...</my:stuff> in JSP) with this syntax? I know,
> Vel. doesn't support it anyway, except for some built-in directives,
> but many template language will definitely want to (like JSP,
> FreeMarker, Viento), for good reason IMO. Now I don't go into the
> endless variations of solutions that I tried "on paper" and then
> thrown away, because they had too many catches, or was too verbose, or
> look far too alien. Can anybody show me a good solution with more-less
> WebMacro (Velocity) style? (And don't forget to count with the text
> editors, for which a syntax highlight should be possible.)
>
> I have rumbled a lot about template syntaxes in the past. I really tried
> to find out syntaxes that have a WebMacro (or Velocity) look-and-feel,
> or just otherwise natural look if you see what I mean. (Note that not
> supporting macros with body is not acceptable for me.) For my biggest
> regret, I have found that at the end of the day, the simplest and most
> reliable syntaxes, the best compromises, were are always those where
> there are strictly required delimiters at the left and right side of the
> directives, like <#...>, or [#...], or even <%...%>, also ${...}, or
> #{...}, etc, i.e. not the WebMacro look-and-feel stuff at all.
> Furthermore at least the left side delimiter should be something that
> doesn't clash with anything that can easily occur in the static text, so
> just [...] is not enough, you need some additional strange character
> after the "[" (and even before the "]" if you want really text-editor
> friendly language). Yes, these syntaxes look alien at the first glance,
> but I believe that after that initial emotional shock (%-/ "Whaaaat?"),
> you will be better with them. They free of ambiguities (no cookbook
> tricks needed), they are safer (less chance of accidental clashes),
> while their rules can still remain damn simple. And, that they are
> necessary more verbose than WebMacro style syntaxes is a myth... they
> are just little bit more verbose, no important difference in that.
>
> --
> Best regards,
> Daniel Dekany
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: What's the ideal syntax?
Posted by Chad Meadows <cm...@us.ibm.com>.
Hi Daniel,
This is what I think might be favorable, at least for me. The ${..}
syntax has become somewhat popular as script substituion in several
contexts such as JSTL, ANT, Jelly etc. For that reason I actually would
prefer all variables in the form ${foo} etc. I like consistency. So I
want to look at some file and easily identify which parts are dynamic or
part of the template script. Therefore, out of the list of delimeters you
mentioned. I actually like #{template directive...} since it has a
resemblance to the variable substitution. It looks more consistent. I
think this will feel much more natural to those who have been exposed to
script in these other contexts. For those who have never seen any script,
I believe it also has more of a visual distinction from xml/html elements
as well.
I as well am not sure if it can be greatly simplified beyond that and
maybe it does not need to be. It is always the case that sometimes
flexibility comes with some complexity. It is not necessarily that anyone
I have shown FreeMarker actually discarded it as an option just because of
the syntax. The syntax is just an inhibitor when at first glance a need
for any of the advanced functions of FreeMarker may not have been in the
requirements. When projects are pushed to the limit on schedules,
adopting what get's the job done with lowest learning curve is often the
choice.
Thanks,
Chad.
What's the ideal syntax? Was: [ANN] Viento - WHY?
Posted by Daniel Dekany <dd...@freemail.hu>.
Friday, October 7, 2005, 11:12:21 PM, Chad Meadows wrote:
> I simply don't quite understand what seems to be a pushback to
> acknowledging there is a community of people who do not like the syntax. I
> have shown the syntax of velocity side by side with freemarker among those
> who had never seen either. Velocity was preferred.
[snip]
DISCLAIMER: This will NOT be a FreeMarker advertisement. Also, I do NOT
like the FreeMarker syntax (but not because of it usage of cryptic
delimiters... there other things historically bungled in it), although I
surely prefer it over Velocity's.
<meta-discussion>
The unimportant thing what I want to say is that Jonathan behaves
roughly in this case because he becomes angry when he faces exactly the
same case of, well, apparent lack of professional experience (read:
***IGNORANCE!!!***, just I don't wanted to say that :)) again and again
and again... the syntax stuff. (Plus, he is pissed of on Jakarta people
in general, so it's not the place where he will try to keep cool his
blood when it wants to boil.)
</meta-discussion>
So, what "apparent lack of professional experience" do I refer to?
One thing is that evaluating a template language primarily based on the
first impression "look and feel" goodness of its syntax is, well... Even
evaluation a template engine primarily based on it syntax is, well...
(as far as the syntax is within the borders of sanity, that is). But let
this alone now too.
The other thing is, that unfortunately a syntax that look simple,
especially one that look good for non-programmer person at the first
glance, always have the dark sides, that are not apparent first. But
later... later you will swallow them because you are already get used to
the basic syntax... but the point is, it turns out that the syntax is
not that good after all. Like, I agree that WebMacro-style syntax (like
Velocity's) looks friendly at the fist glance, but unfortunately it
turns out that this type of syntaxes has some problems, which eventually
fade out the advantage of first-impression natural look (I will not deal
with strictly VTL specific design mistakes and bugs, since those has
trivial fixes):
- To show it in VTL: #else#**#blah#end. I bet most non-programmer will
not figure out easily that they should use that #**#, and anyway it's
awkward. But it could be solved as #{else}blah. Still, then the syntax
has already lost from its minimalism. Because, there are two ways of
writing the same thing, and then wouldn't be simpler if there is only
one way, the way that's always safely works? Anyway, especially for
non-programmers, the delimiting issue is something more mystical than
for a programmer: "Hm.... I don't want space here... will #elseblah be
OK? (try) Sh*t... now what to do? (phone)" (Of course, it's the kind
of thing that the guy will not foresee when he falls in love with Vel.
at the first glance.) But, if you want, let's say it's a minor issue.
- The $foo VS ${foo} thing. The same as with #else basically.
Complicates things... why not just one *safe* way (it's clean for
everybody where's the end of the expression), which is ${foo}. Instead
of two ways? Much simpler, the documentation will be sorter... Yes,
more typing, but I think it worth it in the case of template language.
But, again if you want, let's say it's a minor issue.
- BTW as a side note, with $foo you can really use "complex"
expressions, like ${x + 1}. With ${...} it naturally works.
- Again $foo VS ${foo}. You have high chance that something that meant to
be static text will be interpreted as a reference. Like $Id: ...$
Not a that minor issue... And yet another catch to remember.
- And the most important for the last... how do you call a macro with
body (like <my:stuff>...</my:stuff> in JSP) with this syntax? I know,
Vel. doesn't support it anyway, except for some built-in directives,
but many template language will definitely want to (like JSP,
FreeMarker, Viento), for good reason IMO. Now I don't go into the
endless variations of solutions that I tried "on paper" and then
thrown away, because they had too many catches, or was too verbose, or
look far too alien. Can anybody show me a good solution with more-less
WebMacro (Velocity) style? (And don't forget to count with the text
editors, for which a syntax highlight should be possible.)
I have rumbled a lot about template syntaxes in the past. I really tried
to find out syntaxes that have a WebMacro (or Velocity) look-and-feel,
or just otherwise natural look if you see what I mean. (Note that not
supporting macros with body is not acceptable for me.) For my biggest
regret, I have found that at the end of the day, the simplest and most
reliable syntaxes, the best compromises, were are always those where
there are strictly required delimiters at the left and right side of the
directives, like <#...>, or [#...], or even <%...%>, also ${...}, or
#{...}, etc, i.e. not the WebMacro look-and-feel stuff at all.
Furthermore at least the left side delimiter should be something that
doesn't clash with anything that can easily occur in the static text, so
just [...] is not enough, you need some additional strange character
after the "[" (and even before the "]" if you want really text-editor
friendly language). Yes, these syntaxes look alien at the first glance,
but I believe that after that initial emotional shock (%-/ "Whaaaat?"),
you will be better with them. They free of ambiguities (no cookbook
tricks needed), they are safer (less chance of accidental clashes),
while their rules can still remain damn simple. And, that they are
necessary more verbose than WebMacro style syntaxes is a myth... they
are just little bit more verbose, no important difference in that.
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Chad Meadows <cm...@us.ibm.com>.
I simply don't quite understand what seems to be a pushback to
acknowledging there is a community of people who do not like the syntax. I
have shown the syntax of velocity side by side with freemarker among those
who had never seen either. Velocity was preferred. General responses to
freemarker, "it looks more cryptic. it looks like xml, but is not xml.".
Make of it what you will, that is feedback I have received. You are the
designers, it seems intuitive to you. Apparently it is not for everyone.
Would it be valuable for people to push past what may seem to them to be
an awkward syntax? Yes, certainly, freemarker is very powerful and so are
regular expressions. But there are people who are intimidated by syntax
that does not feel natural. There were a number of people in this thread
that mentioned the simplistic appearance of the velocity syntax was
important in their decision. Should we accuse them all of not knowing how
to use editors and tools for syntax highlighting? or maybe this is
valuable input into how freemarker might evolve into something that an
even greater community will be enthused about. It is up to you to decide
how to use what I perceive as valuable feedback from potential users.
Chad.
Jonathan Revusky <re...@wanadoo.es>
Sent by: news <ne...@sea.gmane.org>
10/07/2005 04:02 PM
Please respond to
"Velocity Users List"
To
velocity-user@jakarta.apache.org
cc
Subject
Re: [ANN] Viento - WHY?
Chad Meadows wrote:
> Yes, it is mainly for the reasons you already stated, plus just on a
> visual level the freeMarker tags don't stand out as well.
Chad, you have heard of syntax highlighting, right? I certainly wouldn't
want to edit code of any sort -- C, python, java, freemarker, whatever
-- in an editor that lacked this feature. All the freemarker directives
use a clearly recognizable (particularly via regexp) pattern <#...> for
the built-in directives and <@....> for user-defined ones. So most any
editing tool can be configured to have these things stand out.
So, if freemarker directives are blue, let's say, and HTML tags are
green, is that standing out well enough for you? (If it's not, use bold
vs. italic as well....) People have donated syntax highlighting
configuration files for various editing environments already, but in any
case, they wouldn't be that hard to set up in general.
So, is this complaint, that FTL directives do not "stand out"
sufficientlhy being made in completely good faith, or is it that people
are this lazy about setting up their editing environments (or those of
other people) so as to be maximally productive?
> Especially to
> people who are not exactly the most XML savvy.
Hmm, well, I'm not sure I see your point. Web designers would be quite
savvy about markup-based code. I would certainly hope that any web
designer I would hire knows HTML far better than *I* do. I try to avoid
HTML frankly.
Do you seriously think that a web designer will think that <#if
user.isLoggedIn> is a regular HTML tag? Even if they do initially
operate under that misconception, how long would it take of using
FreeMarker in their daily work to get this straight?
But particularly with syntax highlighting showing HTML or XML tags in a
different color from the FTL directives...
> I think it is more of a
> first impression thing that sometimes is hard to get over. Seems to
> create some confusion among some people who look at the tags as they
look
> kinda like xml, but they are not xml.
Well, at least, in the early days, when I first started using
FreeMarker, like around late 1999, I thought that the syntax was a win,
simply because you could introduce it (via a white lie) as a new kind of
tag that did certain "stuff". Of course, it's not really that. That's a
sort of useful little white lie(*) to help people get going with
something.
Overall, I do not get the sense that the syntactical issue is anything
like a first-order thing. Probably, if we performed the conceptual
experiment that Velocity had FreeMarker's syntax and vice versa, the
very same people would still be proclaiming that it was FM's syntax that
turns them off of it and that Velocity's was so clean. People just tend
to get used to certain things and then become overly devoted or
religious about them.
> [ and ] seems like a reasonable alternative to me.
That's already available in our CVS trunk.
But anyway, while one hears people saying that they are sticking with
Velocity because of its syntax, I know of no case (it has not come to my
attention anyway) of anybody switching from FreeMarker to Velocity for
the syntax. Actually, I can't think of any cases of people switching
from FreeMarker to Velocity. I pointed out blog entries of people
detailing their experience going from FM->Vel. I don't know of any
similar blog entries detailing a migration the other way round.
Regards,
Jonathan Revusky
(*) I do hope nobody will use this as proof that I am a liar. :-)
>
> Thanks,
>
> Chad.
>
>
>
>
> Daniel Dekany <dd...@freemail.hu>
> 10/07/2005 01:34 PM
> Please respond to
> "Velocity Users List"
>
>
> To
> "Velocity Users List" <ve...@jakarta.apache.org>
> cc
>
> Subject
> Re: [ANN] Viento - WHY?
>
>
>
>
>
>
> Friday, October 7, 2005, 7:14:41 PM, Chad Meadows wrote:
>
>
>>Hi Jonathan,
>>
>>"In any case, if the only reason was the syntax, say, and the semantics
>>and capabilities of FreeMarker were satisfactory, why not just tweak
>>FreeMarker's javacc grammar to use different delimiters that you like
>>better?"
>>
>>Do you have a FAQ or something on FreeMarker which describes this for us
>>who are not familiar with javacc. The syntax issue has been the primary
>>reason that has kept many users away from FreeMarker in my area as well.
>
>
> What exactly was their problem with the syntax?
>
>
>>Just from the sample of emails on this list it would seem this is a very
>>important issue. Some guidance on how to tweak the delimeters may prove
>>to be very valuable.
>
>
> It seems that very soon you can chose between using < and > or [ and ].
> It will be added because many users has reported that he has problems
> because the interferences with the HTML/XML syntax (that < and > are
> reserved in them) confuses certain tools.
>
>
>>Thanks,
>>Chad.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Chad Meadows wrote:
> Yes, it is mainly for the reasons you already stated, plus just on a
> visual level the freeMarker tags don't stand out as well.
Chad, you have heard of syntax highlighting, right? I certainly wouldn't
want to edit code of any sort -- C, python, java, freemarker, whatever
-- in an editor that lacked this feature. All the freemarker directives
use a clearly recognizable (particularly via regexp) pattern <#...> for
the built-in directives and <@....> for user-defined ones. So most any
editing tool can be configured to have these things stand out.
So, if freemarker directives are blue, let's say, and HTML tags are
green, is that standing out well enough for you? (If it's not, use bold
vs. italic as well....) People have donated syntax highlighting
configuration files for various editing environments already, but in any
case, they wouldn't be that hard to set up in general.
So, is this complaint, that FTL directives do not "stand out"
sufficientlhy being made in completely good faith, or is it that people
are this lazy about setting up their editing environments (or those of
other people) so as to be maximally productive?
> Especially to
> people who are not exactly the most XML savvy.
Hmm, well, I'm not sure I see your point. Web designers would be quite
savvy about markup-based code. I would certainly hope that any web
designer I would hire knows HTML far better than *I* do. I try to avoid
HTML frankly.
Do you seriously think that a web designer will think that <#if
user.isLoggedIn> is a regular HTML tag? Even if they do initially
operate under that misconception, how long would it take of using
FreeMarker in their daily work to get this straight?
But particularly with syntax highlighting showing HTML or XML tags in a
different color from the FTL directives...
> I think it is more of a
> first impression thing that sometimes is hard to get over. Seems to
> create some confusion among some people who look at the tags as they look
> kinda like xml, but they are not xml.
Well, at least, in the early days, when I first started using
FreeMarker, like around late 1999, I thought that the syntax was a win,
simply because you could introduce it (via a white lie) as a new kind of
tag that did certain "stuff". Of course, it's not really that. That's a
sort of useful little white lie(*) to help people get going with something.
Overall, I do not get the sense that the syntactical issue is anything
like a first-order thing. Probably, if we performed the conceptual
experiment that Velocity had FreeMarker's syntax and vice versa, the
very same people would still be proclaiming that it was FM's syntax that
turns them off of it and that Velocity's was so clean. People just tend
to get used to certain things and then become overly devoted or
religious about them.
> [ and ] seems like a reasonable alternative to me.
That's already available in our CVS trunk.
But anyway, while one hears people saying that they are sticking with
Velocity because of its syntax, I know of no case (it has not come to my
attention anyway) of anybody switching from FreeMarker to Velocity for
the syntax. Actually, I can't think of any cases of people switching
from FreeMarker to Velocity. I pointed out blog entries of people
detailing their experience going from FM->Vel. I don't know of any
similar blog entries detailing a migration the other way round.
Regards,
Jonathan Revusky
(*) I do hope nobody will use this as proof that I am a liar. :-)
>
> Thanks,
>
> Chad.
>
>
>
>
> Daniel Dekany <dd...@freemail.hu>
> 10/07/2005 01:34 PM
> Please respond to
> "Velocity Users List"
>
>
> To
> "Velocity Users List" <ve...@jakarta.apache.org>
> cc
>
> Subject
> Re: [ANN] Viento - WHY?
>
>
>
>
>
>
> Friday, October 7, 2005, 7:14:41 PM, Chad Meadows wrote:
>
>
>>Hi Jonathan,
>>
>>"In any case, if the only reason was the syntax, say, and the semantics
>>and capabilities of FreeMarker were satisfactory, why not just tweak
>>FreeMarker's javacc grammar to use different delimiters that you like
>>better?"
>>
>>Do you have a FAQ or something on FreeMarker which describes this for us
>>who are not familiar with javacc. The syntax issue has been the primary
>>reason that has kept many users away from FreeMarker in my area as well.
>
>
> What exactly was their problem with the syntax?
>
>
>>Just from the sample of emails on this list it would seem this is a very
>>important issue. Some guidance on how to tweak the delimeters may prove
>>to be very valuable.
>
>
> It seems that very soon you can chose between using < and > or [ and ].
> It will be added because many users has reported that he has problems
> because the interferences with the HTML/XML syntax (that < and > are
> reserved in them) confuses certain tools.
>
>
>>Thanks,
>>Chad.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Chad Meadows <cm...@us.ibm.com>.
Yes, it is mainly for the reasons you already stated, plus just on a
visual level the freeMarker tags don't stand out as well. Especially to
people who are not exactly the most XML savvy. I think it is more of a
first impression thing that sometimes is hard to get over. Seems to
create some confusion among some people who look at the tags as they look
kinda like xml, but they are not xml.
[ and ] seems like a reasonable alternative to me.
Thanks,
Chad.
Daniel Dekany <dd...@freemail.hu>
10/07/2005 01:34 PM
Please respond to
"Velocity Users List"
To
"Velocity Users List" <ve...@jakarta.apache.org>
cc
Subject
Re: [ANN] Viento - WHY?
Friday, October 7, 2005, 7:14:41 PM, Chad Meadows wrote:
> Hi Jonathan,
>
> "In any case, if the only reason was the syntax, say, and the semantics
> and capabilities of FreeMarker were satisfactory, why not just tweak
> FreeMarker's javacc grammar to use different delimiters that you like
> better?"
>
> Do you have a FAQ or something on FreeMarker which describes this for us
> who are not familiar with javacc. The syntax issue has been the primary
> reason that has kept many users away from FreeMarker in my area as well.
What exactly was their problem with the syntax?
> Just from the sample of emails on this list it would seem this is a very
> important issue. Some guidance on how to tweak the delimeters may prove
> to be very valuable.
It seems that very soon you can chose between using < and > or [ and ].
It will be added because many users has reported that he has problems
because the interferences with the HTML/XML syntax (that < and > are
reserved in them) confuses certain tools.
> Thanks,
> Chad.
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Daniel Dekany <dd...@freemail.hu>.
Friday, October 7, 2005, 7:14:41 PM, Chad Meadows wrote:
> Hi Jonathan,
>
> "In any case, if the only reason was the syntax, say, and the semantics
> and capabilities of FreeMarker were satisfactory, why not just tweak
> FreeMarker's javacc grammar to use different delimiters that you like
> better?"
>
> Do you have a FAQ or something on FreeMarker which describes this for us
> who are not familiar with javacc. The syntax issue has been the primary
> reason that has kept many users away from FreeMarker in my area as well.
What exactly was their problem with the syntax?
> Just from the sample of emails on this list it would seem this is a very
> important issue. Some guidance on how to tweak the delimeters may prove
> to be very valuable.
It seems that very soon you can chose between using < and > or [ and ].
It will be added because many users has reported that he has problems
because the interferences with the HTML/XML syntax (that < and > are
reserved in them) confuses certain tools.
> Thanks,
> Chad.
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Adam Williams <ad...@gmail.com>.
On 10/7/05, Jonathan Revusky <re...@wanadoo.es> wrote:
> Well, you're getting some feedback, I'd say.
Yes, this is fun! I haven't seen this many messages on one subject in a while.
> It's impressive that you've
> gotten so far with so little time invested. You must be a talented guy.
I'd say. He went from knowing pretty much nothing about parsing
anything to having a simple template language that does quite a bit in
a very short period of time.
> Nonetheless, talented, energetic people often underestimate the full
> long-term time commitment in projects. If you really are serious about
> this, you're going to put in a lot more time, and I would have to say,
> that it's going to be a lot more than leveraging an already-existing
> codebase would have been.
Has he underestimated the cost of maintaining the project? Yes - he
/is/ a developer. Alas, he is not alone.
>
> Of course, the end result is that you get exactly what you want and so
> on, but surely, it's a lot more work.
>
> > So far, I've heard that we need a better
> > explanation of what's good about it. I could say the same for FreeMarker.
>
> Well, not really. C'mon... FreeMarker is an established, well regarded
> tool of a certain vintage, the project has been around for 6 years and
> has a lot of users -- people using it directly as a library and as a
> component in MVC web frameworks. You have put out something completely
> new, which, by your own admission, has less than 40 hours of your time
> in it. As such, if you want people to give your stuff a try, there is a
> much, much stronger onus on you than on me, for example, to explain why
> they should do so. People have finite time to go try out software
> libraries. To argue that people should devote that time to trying out
> Sails rather than FreeMarker, say, you really have to provide some
> compelling arguments, because a rational person would tend towards the
> more mature, established, tested technology.
>
> (Side note: Maybe statements like the above are what are considered
> "abusive". And they may be harsh, but I say this in completely good
> faith, no malice, and I think it's completely fair.... also, what I am
> saying seems like common sense to me...)
I am learning to consider it all joy when I face various trials, as
all things work together for good for me. I certainly don't take
offense to anything you've said.
Sails is not a template language. It is a solution upon which dynamic
Web2.0 applications can be built. It has been using Velocity for 8
months. Austin and I both looked at changing it, and decided not to.
Viento is a name Austin put on the solution he had for the problems
/we/ are trying to solve for ourselves. Whether anyone else ever finds
it useful or not is obviously of question.
Consider Ant. Created to solve one guy's problems. Now the defacto
build foundation of Java. Good or bad? Some folks love it, some hate.
Some use it, some don't. Did it grow beyond it's creator? Absolutely.
I didn't take time to look at FreeMarker before we chose Velocity,
before Viento, and not much since this thread began. You would likely
never hire me, for lack of diligence in researching all the options.
Then, who has time to try out everything? It is a fact in my mind,
proven over and over, that things are often not what they appear -
especially when that appearance is created by those who created the
thing behind it.
>
> >
> > One of the primary differences, looking closer, is the philosophy of putting
> > real work in Java code, rather than template macros.
>
> Well, if I understand you, I think I disagree with this. Pretty
> strongly... If the macro is clearly display-related logic, why on earth
> should you want to maintain this in Java code?
Pragmatism. Refactoring support. Cleanliness (see your comment below
about 'whitespace-stripping filters' and FTL). Developers, that is,
those that I work with, are ALWAYS involved in making pretty HTML
dynamic. No, I don't believe it is because we have put String
generation in Java. Remember, MVC can be implemented in various ways,
accross more than one 'layer'.
You should look into Ruby on Rails if you write web applications. In
particular, consider all the little methods being called from the
templates. Look at their helpers. They enable RAD, clean AJAX,
understandability. God help me if I ever have to write that kind of
String generation in a Velocimacro, or in any template language. That
is why Apple's Web Objects, Microsoft's ASP.NET, Tapestry, Wicket, etc
etc all have the concept of Components. I don't enjoy programming
/that/ way, but is shows that *presentation logic* is implemented in
various ways, by smart folks.
> The whole point of a
> template engine is to get the display details out of your java code,
> isn't it?
No, not for me. I use a template language because I have to send
Strings to a browser. Writing Strings in Java sucks. No, if it was
easier, I would still use template langauges. A template language can
be thought of as an inversion of a programming language. In a
programming language, almost everything is logic. In a template
language, almost everything is a String.
>
> Still, even if I were to agree with you, it is not an argument against
> FreeMarker per se, since FreeMarker does allow you to implement these
> things on the java side, via the TemplateTransformModel API. It's
> basically the equivalent of what JSP calls filters. And of course,
> certain custom tags have to be implemented that way, such as
> whitespace-stripping filters and so on. They can't really be done
> cleanly on the FTL side.
>
>
> > We used to use macros
> > in Velocity, but soon found that tools were much more robust, easier to
> > maintain, etc.
>
> Well, was this inherently a problem with macros per se or simply because
> Velocity's macro system is quite flakey? I mean, for starters, in
> Velocity, you can't even define a local variable in a macro. Also, you
> can't put a set of macros in a separate mainspace. Any little helper
> variable you define is polluting your main namespace. I mean, in a large
> system, you'd be bound to hit glitches where different pieces of
> template code define a variable called $name or $display or whatever,
> and clobber some variable defined elsewhere.
>
> To say that macros are a bad idea, that the results are not robust,
> solely on the basis of your Velocity experience is not very convincing
> to me...
Granted. Though I still enjoy encapsulating duplication in something
that can be extended, changed, and otherwise arranged in such a
fashion as to make me /feel better/.
adam williams
P.S. My apologies to those who are offended that this discussion
continues on this list. I plan to create user and developer lists over
at opensails.org. Perhaps we can migrate over there. In the meantime,
onsider it edifying or press delete ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Austin Taylor wrote:
>>
>>Jonathan Revusky
>>--
>>lead developer, FreeMarker project, http://freemarker.org/
>>
>>
>
> Yeah, umm, I don't want to argue about what I did. It was much easier for me
> to start from scratch than to modify someone else's existing code base,
> however clean. I haven't put 40 hours into Viento yet. I'm not here to
> promote it, but to get feedback.
Well, you're getting some feedback, I'd say. It's impressive that you've
gotten so far with so little time invested. You must be a talented guy.
Nonetheless, talented, energetic people often underestimate the full
long-term time commitment in projects. If you really are serious about
this, you're going to put in a lot more time, and I would have to say,
that it's going to be a lot more than leveraging an already-existing
codebase would have been.
Of course, the end result is that you get exactly what you want and so
on, but surely, it's a lot more work.
> So far, I've heard that we need a better
> explanation of what's good about it. I could say the same for FreeMarker.
Well, not really. C'mon... FreeMarker is an established, well regarded
tool of a certain vintage, the project has been around for 6 years and
has a lot of users -- people using it directly as a library and as a
component in MVC web frameworks. You have put out something completely
new, which, by your own admission, has less than 40 hours of your time
in it. As such, if you want people to give your stuff a try, there is a
much, much stronger onus on you than on me, for example, to explain why
they should do so. People have finite time to go try out software
libraries. To argue that people should devote that time to trying out
Sails rather than FreeMarker, say, you really have to provide some
compelling arguments, because a rational person would tend towards the
more mature, established, tested technology.
(Side note: Maybe statements like the above are what are considered
"abusive". And they may be harsh, but I say this in completely good
faith, no malice, and I think it's completely fair.... also, what I am
saying seems like common sense to me...)
>
> One of the primary differences, looking closer, is the philosophy of putting
> real work in Java code, rather than template macros.
Well, if I understand you, I think I disagree with this. Pretty
strongly... If the macro is clearly display-related logic, why on earth
should you want to maintain this in Java code? The whole point of a
template engine is to get the display details out of your java code,
isn't it?
Still, even if I were to agree with you, it is not an argument against
FreeMarker per se, since FreeMarker does allow you to implement these
things on the java side, via the TemplateTransformModel API. It's
basically the equivalent of what JSP calls filters. And of course,
certain custom tags have to be implemented that way, such as
whitespace-stripping filters and so on. They can't really be done
cleanly on the FTL side.
> We used to use macros
> in Velocity, but soon found that tools were much more robust, easier to
> maintain, etc.
Well, was this inherently a problem with macros per se or simply because
Velocity's macro system is quite flakey? I mean, for starters, in
Velocity, you can't even define a local variable in a macro. Also, you
can't put a set of macros in a separate mainspace. Any little helper
variable you define is polluting your main namespace. I mean, in a large
system, you'd be bound to hit glitches where different pieces of
template code define a variable called $name or $display or whatever,
and clobber some variable defined elsewhere.
To say that macros are a bad idea, that the results are not robust,
solely on the basis of your Velocity experience is not very convincing
to me...
> The support for blocks in Viento gives us a "nested body"
> like FreeMarker macros, but lets us do the interesting stuff in Java, which
> I think is better.
Well, maybe you just didn't realize that this "interesting stuff" can be
done in Java or in FTL with FreeMarker.
Jonathan
> I would suggest that keeping the programming in Java
> makes for a shallower learning curb for everyone involved.
>
> Austin
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Austin Taylor <au...@gmail.com>.
>
>
> Jonathan Revusky
> --
> lead developer, FreeMarker project, http://freemarker.org/
>
>
Yeah, umm, I don't want to argue about what I did. It was much easier for me
to start from scratch than to modify someone else's existing code base,
however clean. I haven't put 40 hours into Viento yet. I'm not here to
promote it, but to get feedback. So far, I've heard that we need a better
explanation of what's good about it. I could say the same for FreeMarker.
One of the primary differences, looking closer, is the philosophy of putting
real work in Java code, rather than template macros. We used to use macros
in Velocity, but soon found that tools were much more robust, easier to
maintain, etc. The support for blocks in Viento gives us a "nested body"
like FreeMarker macros, but lets us do the interesting stuff in Java, which
I think is better. I would suggest that keeping the programming in Java
makes for a shallower learning curb for everyone involved.
Austin
Re: [ANN] Viento - WHY?
Posted by Chad Meadows <cm...@us.ibm.com>.
Hi Jonathan,
"In any case, if the only reason was the syntax, say, and the semantics
and capabilities of FreeMarker were satisfactory, why not just tweak
FreeMarker's javacc grammar to use different delimiters that you like
better?"
Do you have a FAQ or something on FreeMarker which describes this for us
who are not familiar with javacc. The syntax issue has been the primary
reason that has kept many users away from FreeMarker in my area as well.
Just from the sample of emails on this list it would seem this is a very
important issue. Some guidance on how to tweak the delimeters may prove
to be very valuable.
Thanks,
Chad.
Re: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Austin Taylor wrote:
> Hello everyone, I'm that Austin guy.
>
> Did you look at FreeMarker? Or any other things besides Velocity before
>
>>deciding to roll your own template engine?
>
>
>
> Yes. If we are focused on Velocity, it's because it was our favorite
> template language before I wrote Viento. I can't get over the syntax. I've
> never seen anything (even rhtml) that I like as well as $object.property.
Austin, are you seriously suggesting that writing $object.property is so
much better than writing ${object.property} (or some other such thing)
that this would be a _primary_ consideration in tool selection? To the
extent that you would actually undertake writing your own template engine?
Put yourself in my shoes. I am very eager to get feedback on my work, as
are you, I'm sure. But if somebody told you that the primary reason
that they opted for perl over python, say, was that they liked writing
'elsif' better than 'elif', how would you react?
I mean, you understand, there's this basic dichotomy between form and
structure. As somebody (one of a minority probably) who does know what
an AST (abstract syntax tree) is, you surely understand that the tokens
you use to delimit the structures in your language are the most trivial,
superficial aspect of the thing.
In any case, if the only reason was the syntax, say, and the semantics
and capabilities of FreeMarker were satisfactory, why not just tweak
FreeMarker's javacc grammar to use different delimiters that you like
better? Or you could write your own ideal grammar and basically have a
filter that converted your syntax to FreeMarker's syntax on-the-fly.
That would be some amount of work, of coursae, but an order of magnitude
less work than writing and maintaining your own template engine. Surely
you might consider all your options before embarking on something of
that scale.
But anyway, that you don't like the tokens being used as delimiters in
an open source tool does not strike me as sufficient motivation to roll
your own template engine. Now, I don't really have any reason to
discourage you guys. And maybe you just felt like writing your own
template engine for the fun of it, but the stated *pragmatic* reasons
that you have provided for doing so are very hard to process or frankly,
to take seriously.
Now, of course, the other matter is that I am pretty satisfied that the
syntax issue is largely a red herring. Somebody would get used to
whatever syntax -- *within reason* (maybe XSLT one would never get used
to) -- within a few days of starting to use the tool seriously. But even
if that were the major issue that you claim, it does not, on technical
or pragmatic grounds justify rolling your own template engine. I'm
sorry, I just can't see it.
>
> It's not 100% clear to me what you mean by this. Of course, as the main
>
>>author and maintainer of FreeMarker's parser code, if I don't
>>understand, then I think it's safe to say that most people wouldn't.
>>(I'm not even sure that most people in the market for a template
>>language know what an AST is.)
>
>
>
> Sometimes code makes more sense than English.
Well, maybe, Austin, but my suspicion is that, far more often, when
people cannot express their ideas in clear, plain English, it's because
the ideas in question are rather half-baked.
This could sound insulting, but I really think that if you cannot or
will not express in plain English what the advantages of using Sails
over Velocity or FreeMarker are, then the natural, healthy reaction of
most people should basically be to....(I don't know how else to say
it...)... to not take you seriously.... I mean, I'm sorry, that's just
the way it seems to me.
> This
> class<http://opensails.org/sails/file/org.opensails.viento/src/java/org/opensails/viento/builtins/IfMixin.java>is
> the only code in the system that knows about 'if'. And this
> little guy<http://opensails.org/sails/file/org.opensails.viento/src/java/org/opensails/viento/builtins/IterableMixin.java>is
> solely responsible for list#each. The simplicity and the power
> together
> is what sets Viento apart. Less characters, more extensible.
>
> For one thing, it is not obvious to me why you would ever want to
>
>>override the behavior of something as key to your language as the "if"
>>directive. Add new directives, sure, but, to override core ones like if
>>and so on???
>
>
>
> You wouldn't. It's an illustration of the power available, not a practical
> suggestion on how to use it.
Okay, so Sails is providing me this power to do something that I never
want to do anyway. Okay, fine. Don't you think you should find a
pragmatic example to motivate the discussion?
> It's not like we specifically coded for that
> sort of thing. It's just inherent in the philosophy that the core language
> constructs shouldn't be 'special'. This idea is borrowed from languages like
> ruby and smalltalk. It's partially purism, but I think it's going to turn
> out very useful in Viento. We're just starting to use it ourselves, so we'll
> see.
>
> I don't think a run-of-the-mill person could read the above wiki entry
>
>>and understand what the pros and cons of Sails are as compared to the
>>alternatives. Or I should say 'alternative' in the singular, since you
>>only talk about Velocity.
>
>
>
> We'll work on that.
Well, my comments above may seem harsh, but I encourage you to work on
that, and do feel free to point me to links providing an updated
discussion of this.
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
> Thanks,
> Austin
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Austin Taylor <au...@gmail.com>.
Hello everyone, I'm that Austin guy.
Did you look at FreeMarker? Or any other things besides Velocity before
> deciding to roll your own template engine?
Yes. If we are focused on Velocity, it's because it was our favorite
template language before I wrote Viento. I can't get over the syntax. I've
never seen anything (even rhtml) that I like as well as $object.property.
It's not 100% clear to me what you mean by this. Of course, as the main
> author and maintainer of FreeMarker's parser code, if I don't
> understand, then I think it's safe to say that most people wouldn't.
> (I'm not even sure that most people in the market for a template
> language know what an AST is.)
Sometimes code makes more sense than English. This
class<http://opensails.org/sails/file/org.opensails.viento/src/java/org/opensails/viento/builtins/IfMixin.java>is
the only code in the system that knows about 'if'. And this
little guy<http://opensails.org/sails/file/org.opensails.viento/src/java/org/opensails/viento/builtins/IterableMixin.java>is
solely responsible for list#each. The simplicity and the power
together
is what sets Viento apart. Less characters, more extensible.
For one thing, it is not obvious to me why you would ever want to
> override the behavior of something as key to your language as the "if"
> directive. Add new directives, sure, but, to override core ones like if
> and so on???
You wouldn't. It's an illustration of the power available, not a practical
suggestion on how to use it. It's not like we specifically coded for that
sort of thing. It's just inherent in the philosophy that the core language
constructs shouldn't be 'special'. This idea is borrowed from languages like
ruby and smalltalk. It's partially purism, but I think it's going to turn
out very useful in Viento. We're just starting to use it ourselves, so we'll
see.
I don't think a run-of-the-mill person could read the above wiki entry
> and understand what the pros and cons of Sails are as compared to the
> alternatives. Or I should say 'alternative' in the singular, since you
> only talk about Velocity.
We'll work on that.
Thanks,
Austin
Re: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Adam Williams wrote:
> On 10/6/05, Daniel Dekany <dd...@freemail.hu> wrote:
>
>>Thursday, October 6, 2005, 1:31:47 PM, Steve O'Hara wrote:
>>
>>
>>>Am I missing something here......??
>>>
>>>There seems to be a whole load of template laguages springing up all
>>>over the place that look very similar to Velocity, each claiming it
>>>solves a view problem that Velocity doesn't.
>
>
> Thanks for the discussion. What doesn't kill you makes you stronger ;)
>
> For one thing, in-line maps don't work in Velocity. I looked into
> fixing that, and even offered $100US to this list (which I hereby
> revoke), but I couldn't figure out how to fix it quickly enough that
> day.
Well, FreeMarker has inline maps, of course -- as well as plenty of
other (more important) things that are lacking in Velocity.
Did you look at FreeMarker? Or any other things besides Velocity before
deciding to roll your own template engine?
>
> Aside from that, I can only say again, Velocity is great, but didn't
> fit our needs. If you like it, and have no need to change, don't. I
> for one am often overwhelmed by the number of options the Java
> community has. Rails has addressed this by giving the gift of not
> /having/ to choose. It is cheaper not to. We want to capture that in
> Sails.
>
> For those who care, what we really needed was a way to extend the
> language at runtime, differently for each Sails application, that is
> easy and consistent. For example, the if in Viento is just a Class,
> exposed as 'if'. You can override that, for any particular template,
> easily. Or, you can take any other object and 'mixin' to your
> template's binding. Velocity can be extended by 1) creating a custom
> directive (that seemed really hard to do, but I'm slow), 2) writing
> custom macros, which aren't as easily tested 3) pojo tools. I know
> about the Uberspect - it seemed that we would have needed to rewrite
> it to acheive a few of our goals.
>
> While Viento is /reminiscent/ of Velocity, it's core design is
> /completely different/. This design enables
> * A succinct syntax (which is what we loved about Velocity)
> * Extreme consistency
> * Core language constructs are implemented with no knowledge of
> parser/ast, and can be replaced - you can write more (for instance, at
> this time there is no #set equivalent, but it would only be a few
> lines of code, with no parser/ast changes)
> * Mixed in instances have no knowledge of the ast. Did I say that already?
It's not 100% clear to me what you mean by this. Of course, as the main
author and maintainer of FreeMarker's parser code, if I don't
understand, then I think it's safe to say that most people wouldn't.
(I'm not even sure that most people in the market for a template
language know what an AST is.)
For one thing, it is not obvious to me why you would ever want to
override the behavior of something as key to your language as the "if"
directive. Add new directives, sure, but, to override core ones like if
and so on???
>
> Anywho, there is probably more I can say, but I'll stop doing so on
> this list. There might be more at
> http://opensails.org/sails/wiki/VientoAndOtherTemplateLanguages - we
> can work there.
I don't think a run-of-the-mill person could read the above wiki entry
and understand what the pros and cons of Sails are as compared to the
alternatives. Or I should say 'alternative' in the singular, since you
only talk about Velocity.
Jonathan Revusky
--
freemarker project, http://freemarker.org/
>
> Thank you so much for your time. Hope to see you Sailing someday....
>
> adam williams
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Will Glass-Husain <wg...@forio.com>.
Thanks for the detailed discussion. There's definitely a big advantage
sometimes in starting from scratch. Adding new features whil keeping things
consistent for existing users can be very difficult. The downside of
starting fresh is that you need to build up a new community instead of
adding to an existing one. But I agree with Henning, both are very valid
choices.
The runtime language pluggability sounds interesting.
Incidentally, by "inline maps" do you mean literal maps as arguments to
methods? I fixed this bug a couple of weeks ago - look for it in the
upcoming Velocity 1.5 release. We're shooting for a fairly significant
release this fall.
(I'll pass on the bounty, but thanks).
Cheers, WILL
----- Original Message -----
From: "Adam Williams" <ad...@gmail.com>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: Thursday, October 06, 2005 12:18 PM
Subject: Re: [ANN] Viento - WHY?
On 10/6/05, Daniel Dekany <dd...@freemail.hu> wrote:
> Thursday, October 6, 2005, 1:31:47 PM, Steve O'Hara wrote:
>
> >
> > Am I missing something here......??
> >
> > There seems to be a whole load of template laguages springing up all
> > over the place that look very similar to Velocity, each claiming it
> > solves a view problem that Velocity doesn't.
Thanks for the discussion. What doesn't kill you makes you stronger ;)
For one thing, in-line maps don't work in Velocity. I looked into
fixing that, and even offered $100US to this list (which I hereby
revoke), but I couldn't figure out how to fix it quickly enough that
day.
Aside from that, I can only say again, Velocity is great, but didn't
fit our needs. If you like it, and have no need to change, don't. I
for one am often overwhelmed by the number of options the Java
community has. Rails has addressed this by giving the gift of not
/having/ to choose. It is cheaper not to. We want to capture that in
Sails.
For those who care, what we really needed was a way to extend the
language at runtime, differently for each Sails application, that is
easy and consistent. For example, the if in Viento is just a Class,
exposed as 'if'. You can override that, for any particular template,
easily. Or, you can take any other object and 'mixin' to your
template's binding. Velocity can be extended by 1) creating a custom
directive (that seemed really hard to do, but I'm slow), 2) writing
custom macros, which aren't as easily tested 3) pojo tools. I know
about the Uberspect - it seemed that we would have needed to rewrite
it to acheive a few of our goals.
While Viento is /reminiscent/ of Velocity, it's core design is
/completely different/. This design enables
* A succinct syntax (which is what we loved about Velocity)
* Extreme consistency
* Core language constructs are implemented with no knowledge of
parser/ast, and can be replaced - you can write more (for instance, at
this time there is no #set equivalent, but it would only be a few
lines of code, with no parser/ast changes)
* Mixed in instances have no knowledge of the ast. Did I say that already?
Anywho, there is probably more I can say, but I'll stop doing so on
this list. There might be more at
http://opensails.org/sails/wiki/VientoAndOtherTemplateLanguages - we
can work there.
Thank you so much for your time. Hope to see you Sailing someday....
adam williams
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Adam Williams <ad...@gmail.com>.
On 10/6/05, Daniel Dekany <dd...@freemail.hu> wrote:
> Thursday, October 6, 2005, 1:31:47 PM, Steve O'Hara wrote:
>
> >
> > Am I missing something here......??
> >
> > There seems to be a whole load of template laguages springing up all
> > over the place that look very similar to Velocity, each claiming it
> > solves a view problem that Velocity doesn't.
Thanks for the discussion. What doesn't kill you makes you stronger ;)
For one thing, in-line maps don't work in Velocity. I looked into
fixing that, and even offered $100US to this list (which I hereby
revoke), but I couldn't figure out how to fix it quickly enough that
day.
Aside from that, I can only say again, Velocity is great, but didn't
fit our needs. If you like it, and have no need to change, don't. I
for one am often overwhelmed by the number of options the Java
community has. Rails has addressed this by giving the gift of not
/having/ to choose. It is cheaper not to. We want to capture that in
Sails.
For those who care, what we really needed was a way to extend the
language at runtime, differently for each Sails application, that is
easy and consistent. For example, the if in Viento is just a Class,
exposed as 'if'. You can override that, for any particular template,
easily. Or, you can take any other object and 'mixin' to your
template's binding. Velocity can be extended by 1) creating a custom
directive (that seemed really hard to do, but I'm slow), 2) writing
custom macros, which aren't as easily tested 3) pojo tools. I know
about the Uberspect - it seemed that we would have needed to rewrite
it to acheive a few of our goals.
While Viento is /reminiscent/ of Velocity, it's core design is
/completely different/. This design enables
* A succinct syntax (which is what we loved about Velocity)
* Extreme consistency
* Core language constructs are implemented with no knowledge of
parser/ast, and can be replaced - you can write more (for instance, at
this time there is no #set equivalent, but it would only be a few
lines of code, with no parser/ast changes)
* Mixed in instances have no knowledge of the ast. Did I say that already?
Anywho, there is probably more I can say, but I'll stop doing so on
this list. There might be more at
http://opensails.org/sails/wiki/VientoAndOtherTemplateLanguages - we
can work there.
Thank you so much for your time. Hope to see you Sailing someday....
adam williams
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Daniel Dekany <dd...@freemail.hu>.
Thursday, October 6, 2005, 1:31:47 PM, Steve O'Hara wrote:
>
> Am I missing something here......??
>
> There seems to be a whole load of template laguages springing up all
> over the place that look very similar to Velocity, each claiming it
> solves a view problem that Velocity doesn't.
>
> I've always assumed that Velocity is a "work in progress" and
> contributions from programmers that improve it are always welcome. So
> why aren't these FreeMarker/Viento/TomDick&Harry developers contributing
> to Velocity rather than creating yet another clone?
For example because you usually can't add new features without upset the
original approach of the existing template engine, and without doing lot
of non-BC things. That's the way of evolution... sometimes it needs
revolutoins. Complete rewrites, that is.
Another reason is usually that the core developers of a given template
engine usually don't agree with too revolutionary ideas, or at least you
have to debate with them a lot until they get what you are talking
about. It's tiresome... also maybe neither party is right, just the have
different taste. So people rather go and work out his own ideas alone,
where they don't have to fight to be understood. This is also very valid
reason.
As of FreeMarker, AFAIK it was written earlier than Velocity... So why
aren't these Velocity developers rather contribute to FreeMarker, rather
than creating yet another one. ;) Just kidding of course...
> I don't have any axe to grind either way but it seems a little odd to
> keep developing new code bases for essentailly the same thing.
It's not at all. The same thing can be solved in a lot of ways, and
neither is clearly the best, except for very trivial tasks (and template
engine design is very very far from trivial). Also, if a solution
exists, experiences accumulate, and thus naturally people will have
better ideas.
> I'm all for step changed developments, but as far as I can make out,
> most of these other tools are just slight improvements on the
> original.
Well... I can't resist to note that you say this on a the wrong list. At
I least I guess that if somebody's, then it's ASF's passion to recreate
already existing projects, mostly just so there will be an in-house
solution (not-invented-here policy). I.e. not because they feel they
have some new ideas and want to scratch the itch.
***
WARNING: I do NOT meant to say opinion about this policy here, if it's
bad or good. That is, now don't start kicking me on balls again! :)
***
Like, Velocity is maybe a good example of this (with the WebMacro fuss).
Or, Geronimo recently. You could ask: why they didn't contribute to
JBoss or ObjectWeb's Jonas? Wait, I know! They wanted a J2EE
implementation by which users can "win a 42'' Plasma HDTV or Sony(tm)
PSP"? :) Ehhh, sorry, I have found it so funny... go to sf.net and see
if you don't understand.
> Can anyone enlighten me?
>
> Steve
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Adam Williams <ad...@gmail.com>.
On 10/7/05, Andrew Mason <an...@assertis.co.uk> wrote:
> Just on that note, I've got a designer who is not very technical . He has
> absolutely no trouble with velocity syntax what so ever. It has taken all of
> a day for him to learn, and he's now able to do some reasonably advanced
> stuff with his templates. Now i'm not saying other templating tools aren't
> good, but velocity's syntax is one of its most powerful features.
Agreed. Thank you WebMacro and Velocity.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Andrew Mason wrote:
> Just on that note, I've got a designer who is not very technical . He has
> absolutely no trouble with velocity syntax what so ever. It has taken all of
> a day for him to learn, and he's now able to do some reasonably advanced
> stuff with his templates. Now i'm not saying other templating tools aren't
> good, but velocity's syntax is one of its most powerful features.
??? I don't see a smiley here.... I guess you're serious....
Well, I guess there's some tendency nowadays just to use the term
"powerful" as a generic synonym for "good". But still, one should
maintain a certain level of discourse, and consider what one is saying,
I think...
To me, this is such an absurd statement. It's like saying that the seats
in a car or the color it is painted are its most "powerful" features.
That a template language uses:
<#if user.isLoggedIn>
...
</#if>
or uses
#if ($user.isLoggedIn)
...
#end
simply cannot make it any more or less "powerful". Surely it is obvious
that this does not affect the thing's *capabilities* in any way
whatsoever!!! Surely that's obvious, isn't it???
It's the underlying semantics of a language that make it a more or less
powerful tool, not its syntax.
Frankly, I really believe that any fair-minded observer would have to
class this as a red herring issue. Anybody who became comfortable with
either one of the syntaxes above for an if statement within a day or so
of using it, would also get comfortable with the other one within about
the same time period.
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Andrew Mason <an...@assertis.co.uk>.
Just on that note, I've got a designer who is not very technical . He has
absolutely no trouble with velocity syntax what so ever. It has taken all of
a day for him to learn, and he's now able to do some reasonably advanced
stuff with his templates. Now i'm not saying other templating tools aren't
good, but velocity's syntax is one of its most powerful features.
On Fri October 7 2005 5:28 pm, jian chen wrote:
> Hi,
>
> I have been looking at the FreeMarker vs. Velocity emails. The only
> objection that I don't use FreeMarker in my project is, I prefer the
> Velocity syntax to FreeMarker. I like a clear separation of the template
> code from the HTML.
>
> Just my 2 cents,
>
> Cheers,
>
> Jian
>
> On 10/7/05, Jonathan Revusky <re...@wanadoo.es> wrote:
> > Malcolm Edgar wrote:
> > > All good stuff..
> > >
> > > FreeMaker is pretty cool, however I ended up using Velocity because of
> >
> > its
> >
> > > simplicity and because the Velocity directives don't look like
> > > xml/html:
> > >
> > > http://click.sourceforge.net/docs/faq.html#why-velocity
> >
> > Well, you're certainly free to opt for whatever tools you like. Also,
> > the existence of FreeMarker, even if you choose not to use it (for now
> > at least :-)) only gives you more options. (Also, FM's existence and
> > continued development puts some pressure on the Velocity developers to
> > get their act together, which benefits you and other Velocity users.)
> >
> > Anyway, as regards your link above, I had come across that in various
> > web surfing/googling and had a few comments that I intended to make, but
> > never got around to it.
> >
> > In the above linked page, you point out (correctly) that FreeMarker
> > clearly has better error reporting than Velocity. (For example, this was
> > one of the reasons cited by the Webwork people for their migration.)
> > However, you then provide examples of how your Click framework mitigates
> > that.
> >
> > You provide a link to the following error page provided by your
> > framework.
> >
> > http://click.sourceforge.net/docs/error-npe.html
> >
> > Now, I think this kind of does beg the question a bit. Most of the time
> > you have a null pointer sort of problem in the template engine space is
> > when somebody misspells the name of a variable in some way. They write:
> >
> > ${user.first_name}
> >
> > when it should be:
> >
> > ${user.firstName}
> >
> > or vice versa or whatever. And in general, people are not very good
> > spellers for the most part and it's very easy to make such mistakes.
> >
> > But when somebody on the template level makes such a mistake, what good
> > does it do that person to get a java stack trace? Surely what they need
> > is the line number location in the template file where the mistake was
> > made.
> >
> > Software is built in many layers and people are typically working on a
> > given layer and other people on another layer, and thus, a division of
> > labor is achieved.
> >
> > By analogy, if I try to reference a null in java code, but get a stack
> > trace showing me where the problem was triggered in the underlying C
> > code in the JVM, how useful would this be for me as a java programmer
> > working on that layer? I am working at one layer (the java code) and it
> > is giving me an error message wrt another, lower layer (the C code in
> > the JVM.)
> >
> > Surely you see my point, right? Meanwhile, by way of contrast to the
> > error page from Click that you show above, here is what a similar error
> > message from FreeMarker outputs:
> >
> > Expression foobar is undefined on line 2, column 3 in bar.ftl.
> > The problematic instruction:
> > ----------
> > ==> ${foobar} [on line 2, column 1 in bar.ftl]
> > in include "bar.ftl" [on line 2, column 1 in foo.ftl]
> > ----------
> >
> > Java backtrace for programmers:
> > ----------
> > freemarker.core.InvalidReferenceException: Expression foobar is
> > undefined on line 2, column 3 in bar.ftl.
> > at
> > freemarker.core.TemplateObject.assertNonNull(TemplateObject.java:124)
> > at freemarker.core.Expression.getStringValue(Expression.java:118)
> > at freemarker.core.Expression.getStringValue(Expression.java:93)
> > at freemarker.core.DollarVariable.accept(DollarVariable.java:76)
> > at freemarker.core.Environment.visit(Environment.java:196)
> > at freemarker.core.MixedContent.accept(MixedContent.java:92)
> > at freemarker.core.Environment.visit(Environment.java:196)
> > at freemarker.core.Environment.include(Environment.java:1365)
> > at freemarker.core.Include.accept(Include.java:155)
> > at freemarker.core.Environment.visit(Environment.java:196)
> > at freemarker.core.MixedContent.accept(MixedContent.java:92)
> > at freemarker.core.Environment.visit(Environment.java:196)
> > at freemarker.core.Environment.process(Environment.java:176)
> > at freemarker.template.Template.process(Template.java:231)
> > <etcetera>
> >
> >
> > You see my point, I'm sure. The error message tells the template writer
> > where the error occurred *at the level he or she is working at*, i.e.
> > the line/column information in the template file. (And, of course, it
> > does provide the java stack trace that could be copy/pasted in an email
> > to the java developers, if necessary.)
> >
> > Now, I grant that using your framework probably does offer substantial
> > advantages over using Velocity alone -- in this and other regards.
> > However, to imply that it fully addresses the error reporting problems
> > inherent in Velocity (as compared to FreeMarker) is clearly incorrect.
> >
> > Since you did basically bring this up by pointing to this link, I think
> > it is only proper that I should point this out.
> >
> > Regards,
> >
> > Jonathan Revusky
> > --
> > lead developer, FreeMarker project, http://freemarker.org/
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Michael Heuer wrote:
> Hello,
>
> I have also been looking at the FreeMarker vs. Velocity emails.
Interesting. Was this of your own free will or was somebody forcing you
to read them?
>
> This is the Velocity users list. Take it elsewhere, please.
Michael, on any given list that you subscribe to, there are going to be
some threads that interest you and you follow them and other threads
that you don't follow because they don't interest you.
Each message I have written is an on-topic reply to some other post that
somebody else made. In turn, other people are responding to my messages.
And so on, in turn. IOW, a discussion has developed. Why should I an the
other people in such a discussion stop talking just because you tell us
to? Unless somebody is forcing you to follow a given thread or
discussion, its existence does not impose any burden on you.
Jonathan Revusky
--
freemarker project, http://freemarker.org/
>
> michael
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Robert Koberg <ro...@koberg.com>.
Henning P. Schmiedehausen wrote:
> Daniel Dekany <dd...@freemail.hu> writes:
>
>
>>Why do you pass trough a template (rather than it's output) an XML
>>parser? I ask because I hear it a lot... if only one people needs it,
>>fine. But why is this demand so popular? For what do people use this?
>
>
> http://xmlgraphics.apache.org/fop/
Sure (though I loath PDF). I use XML content(sometimes with velocity
inline) that is transformed by XSL. We (my CMS) generate the pages out
to a file that can be viewed in a browser whether there is a velocity
parse or not, and it will look correct (most of the sites wew do are
70-100% static content). I encourage velocity code being put in comments
so it is ignored by the browser when not parsed by velocity. By
pregenerating pages you also get a basic caching. The only thing left to
do is a simple velocity parse at runtime.
I need a syntax that can be passed through an XML parser, whether it is
in XML content or in the XSL templates. XML can be passed through
SAX/XSL filters before coming out to the browser (or what-have-you). You
need well-formed XML for that. I also like to output in a standards
compliant way. The current recommendation from the W3C with regard to
the web is XHTML, which is XML.
When using XSL to transform XML to XML you cannot output non-XML, at
least without ugly hacks. (In fact our CMS brochure-website still
outputs JSP for the dynamic stuff, just haven't had the time to switch
to velocity.) To me, it is easier to use XSL to create page structure
(call me crazy :). There really are other people out there who like XSL
too :).
I would use XSL for the runtime templating language, if you (actually
the transformation) didn't need to create a (optimized) DOM for each
source document. That is not that big of a deal in most cases. The main
problem seems to be that the normal template author cannot wrap their
head around XSL, so I have looked for a syntax that is both easy and XML
friendly (and java). When I looked and still to this day (with regard to
released versions) that is only velocity.
best,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Daniel Dekany <dd...@freemail.hu> writes:
>Why do you pass trough a template (rather than it's output) an XML
>parser? I ask because I hear it a lot... if only one people needs it,
>fine. But why is this demand so popular? For what do people use this?
http://xmlgraphics.apache.org/fop/
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: user-written templates / reflection safety
Posted by Henning Schmiedehausen <hp...@intermeta.de>.
On Sun, 2005-10-09 at 15:09 +0200, Daniel Dekany wrote:
> I agree, but how to limit the maximum runtime? One could start a thread
> for template executing and then stop it, but stopping threads is not
> safe (and thus is deprecated).
Don't stop the Thead directly. Be creative. :-)
e.g. register the time when entering the parsing process. Add a method
to your nodes that compares the starting time to the current time when
processing the node. Abort processing when currTime > startTime +
allowedRunTime.
Or use a variant that involves a thread based trigger and just a flag
check in the node processing. As long as you don't allow custom Java
code to be executed and trust the code that you allow to be executed,
you will hit the various tree nodes on a pretty regular base.
Not an exact measurement but this not runtime accounting anyway.
As I said: You might impose a performance penalty on all the other
users. That's why you have to think about it.
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development
Linux, Java, perl, Solaris -- Consulting, Training, Engineering
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: user-written templates / reflection safety
Posted by Jason Pettiss <ja...@TheCatalis.com>.
Yeah I don't think anyone seriously needs this, but the as far as I can
see the only way to get a near-infinite sized template from one that
fits in a certain quota space is by repeatedly looping (since I think
there is a maximum total depth for macros so even a circular macro would
get stopped pretty early). So I was thinking you could put the total
execution time check at that point.
But now that I think about it, I suppose if wrap the Writer with a
decorated BufferedWriter such that the flush() method does the check,
you'll get much more granular control. And if the time expires, you
just just throw an exception and it'll be right in the thread that is
executing the template.
--jason
Daniel Dekany wrote:
>Sunday, October 9, 2005, 11:15:19 AM, Henning P. Schmiedehausen wrote:
>
>
>
>>Jason Pettiss <ja...@TheCatalis.com> writes:
>>
>>
>>
>>>I agree with you, writing a language to guard against truly malicious
>>>behavior only penalizes the rest of us. But let's say you're a hosting
>>>provider and you let people upload the scripts as part of their personal
>>>hosting and you provide them all the APIs which you think are 'safe' and
>>>will not be time consuming. Then the question is-- what could you do to
>>>keep them from hosing your server?
>>>
>>>
>>You would do what everyone that was ever involved with that kind of
>>shared hosting environment does: Limit the maximum run time of a
>>script. Like httpd does.
>>
>>But counting iterations on a loop is IMHO not the right thing to do.
>>
>>
>
>I agree, but how to limit the maximum runtime? One could start a thread
>for template executing and then stop it, but stopping threads is not
>safe (and thus is deprecated).
>
>
>
>>However, if you start optimizing an application to some border cases
>>(and IMHO having shared environments that allow potential malicious
>>users to upload templates is not actually a very common use case), you
>>must make sure that you neither penalize "regular" use cases nor go
>>overboard in what you restrict the regular use cases.
>>
>>>From this comes reluctance to implement "feature of the day" that
>>might have popped up on a list somewhere. I understand that this is
>>often perceived as "developers not listening to users".
>>
>>
>
>(I don't remember that there where anything like that said about this
>particular issue...)
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: user-written templates / reflection safety
Posted by Daniel Dekany <dd...@freemail.hu>.
Sunday, October 9, 2005, 11:15:19 AM, Henning P. Schmiedehausen wrote:
> Jason Pettiss <ja...@TheCatalis.com> writes:
>
>>I agree with you, writing a language to guard against truly malicious
>>behavior only penalizes the rest of us. But let's say you're a hosting
>>provider and you let people upload the scripts as part of their personal
>>hosting and you provide them all the APIs which you think are 'safe' and
>>will not be time consuming. Then the question is-- what could you do to
>>keep them from hosing your server?
>
> You would do what everyone that was ever involved with that kind of
> shared hosting environment does: Limit the maximum run time of a
> script. Like httpd does.
>
> But counting iterations on a loop is IMHO not the right thing to do.
I agree, but how to limit the maximum runtime? One could start a thread
for template executing and then stop it, but stopping threads is not
safe (and thus is deprecated).
> However, if you start optimizing an application to some border cases
> (and IMHO having shared environments that allow potential malicious
> users to upload templates is not actually a very common use case), you
> must make sure that you neither penalize "regular" use cases nor go
> overboard in what you restrict the regular use cases.
>
> From this comes reluctance to implement "feature of the day" that
> might have popped up on a list somewhere. I understand that this is
> often perceived as "developers not listening to users".
(I don't remember that there where anything like that said about this
particular issue...)
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: user-written templates / reflection safety
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Jason Pettiss <ja...@TheCatalis.com> writes:
>I agree with you, writing a language to guard against truly malicious
>behavior only penalizes the rest of us. But let's say you're a hosting
>provider and you let people upload the scripts as part of their personal
>hosting and you provide them all the APIs which you think are 'safe' and
>will not be time consuming. Then the question is-- what could you do to
>keep them from hosing your server?
You would do what everyone that was ever involved with that kind of
shared hosting environment does: Limit the maximum run time of a
script. Like httpd does.
But counting iterations on a loop is IMHO not the right thing to do.
However, if you start optimizing an application to some border cases
(and IMHO having shared environments that allow potential malicious
users to upload templates is not actually a very common use case), you
must make sure that you neither penalize "regular" use cases nor go
overboard in what you restrict the regular use cases.
>From this comes reluctance to implement "feature of the day" that
might have popped up on a list somewhere. I understand that this is
often perceived as "developers not listening to users".
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: user-written templates / reflection safety
Posted by Jason Pettiss <ja...@TheCatalis.com>.
I agree with you, writing a language to guard against truly malicious
behavior only penalizes the rest of us. But let's say you're a hosting
provider and you let people upload the scripts as part of their personal
hosting and you provide them all the APIs which you think are 'safe' and
will not be time consuming. Then the question is-- what could you do to
keep them from hosing your server?
So yeah, what you say-- keep a running count of the number of total
iterations of all loops on the page. If this is an HTML page and there
are more than, say, 4 million, clearly there is something wrong. ;-)
So you interrupt it and just spit out an incomplete page. Or, if the
total output is larger than a certain amount, you shut it down. Then as
long as your APIs are really restrictive and well designed, then people
shouldn't be able to hose you too bad...
James Kebinger wrote:
>So what do you want? A limit on how big one's loop variable can be? You
>can't prevent every action by a completely pathological user other than by
>not letting them upload arbitrary scripts.
>
>On 10/7/05, Daniel Dekany <dd...@freemail.hu> wrote:
>
>
>>Friday, October 7, 2005, 8:11:02 PM, Will Glass-Husain wrote:
>>
>>
>>
>>>Hi,
>>>
>>>(pls change the subject line when you change topic - thanks!)
>>>
>>>Just as a quick side note... I have hundreds of users writing their
>>>
>>>
>>Velocity
>>
>>
>>>own templates and uploading them to my system. You need a custom
>>>uberspector to prevent evil reflection (this will be standard in v1.6).
>>>
>>>
>>I
>>
>>
>>>am also cautious about what objects and methods are in the context
>>>
>>>
>>(users do
>>
>>
>>>not have control of this). Infinite loops are not possible with the
>>>#foreach directive.
>>>
>>>
>>When I said "practically infinite loop" then I meant something like:
>>
>>#foreach( $a in [1..9999999] )
>>#foreach( $b in [1..9999999] )
>>#foreach( $c in [1..9999999] )
>>#foreach( $d in [1..9999999] )
>>#foreach( $e in [1..9999999] )
>>#foreach( $f in [1..9999999] )
>>#foreach( $g in [1..9999999] )
>>Mmmmmuhahahaha!
>>#end
>>#end
>>#end
>>#end
>>#end
>>#end
>>#end
>>
>>I would think it's a problem.
>>
>>
>>
>>>Finally, I use a Java security policy file for extra
>>>protection.
>>>
>>>See this essay for some more thoughts on this matter.
>>>http://wiki.apache.org/jakarta-velocity/BuildingSecureWebApplications
>>>
>>>WILL
>>>
>>>
>>--
>>Best regards,
>>Daniel Dekany
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: user-written templates / reflection safety
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Will Glass-Husain" <wg...@forio.com> writes:
>We host sensitive corporate information, so I'm most concerned about people
>accessing confidential data (or messing with server files). Preventing
>reflection and changing the behavior of #include / #parse should be
>effective. Preventing a DOS attack is harder. I think our volume of users
>is low enough that when our "server-in-trouble" pager goes off I'd just kill
>the offender's account. But practically speaking I don't expect this ever
>to happen.
Don't think "malicious". Think "stupid". Everyone of us has at some
point programmed endless loops in programs. While it is hard in
Velocity, it is not impossible. :-)
Limiting the runtime of a template is a possible option.
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: user-written templates / reflection safety
Posted by Will Glass-Husain <wg...@forio.com>.
It's a tricky question. I've thought a lot about this. So far we've been
going 4 years and (to my knowledge) no one has attempted this.
We host sensitive corporate information, so I'm most concerned about people
accessing confidential data (or messing with server files). Preventing
reflection and changing the behavior of #include / #parse should be
effective. Preventing a DOS attack is harder. I think our volume of users
is low enough that when our "server-in-trouble" pager goes off I'd just kill
the offender's account. But practically speaking I don't expect this ever
to happen.
WILL
----- Original Message -----
From: "Daniel Dekany" <dd...@freemail.hu>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: Saturday, October 08, 2005 4:24 PM
Subject: Re: user-written templates / reflection safety
> Saturday, October 8, 2005, 8:31:19 PM, James Kebinger wrote:
>
>> So what do you want?
>
> Nothing... I have just said that your site still will not be safe after
> you have prevented the calling of arbitrary Java API methods from the
> templates. There are other ways of attack.
>
>> A limit on how big one's loop variable can be? You can't prevent every
>> action by a completely pathological user other than by not letting
>> them upload arbitrary scripts.
>
> And that's what I said.
>
> --
> Best regards,
> Daniel Dekany
>
>> On 10/7/05, Daniel Dekany <dd...@freemail.hu> wrote:
>>>
>>> Friday, October 7, 2005, 8:11:02 PM, Will Glass-Husain wrote:
>>>
>>> > Hi,
>>> >
>>> > (pls change the subject line when you change topic - thanks!)
>>> >
>>> > Just as a quick side note... I have hundreds of users writing their
>>> Velocity
>>> > own templates and uploading them to my system. You need a custom
>>> > uberspector to prevent evil reflection (this will be standard in
>>> > v1.6).
>>> I
>>> > am also cautious about what objects and methods are in the context
>>> (users do
>>> > not have control of this). Infinite loops are not possible with the
>>> > #foreach directive.
>>>
>>> When I said "practically infinite loop" then I meant something like:
>>>
>>> #foreach( $a in [1..9999999] )
>>> #foreach( $b in [1..9999999] )
>>> #foreach( $c in [1..9999999] )
>>> #foreach( $d in [1..9999999] )
>>> #foreach( $e in [1..9999999] )
>>> #foreach( $f in [1..9999999] )
>>> #foreach( $g in [1..9999999] )
>>> Mmmmmuhahahaha!
>>> #end
>>> #end
>>> #end
>>> #end
>>> #end
>>> #end
>>> #end
>>>
>>> I would think it's a problem.
>>>
>>> > Finally, I use a Java security policy file for extra
>>> > protection.
>>> >
>>> > See this essay for some more thoughts on this matter.
>>> >
>>> http://wiki.apache.org/jakarta-velocity/BuildingSecureWebApplications
>>> >
>>> > WILL
>>>
>>> --
>>> Best regards,
>>> Daniel Dekany
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:
>>> velocity-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: user-written templates / reflection safety
Posted by Daniel Dekany <dd...@freemail.hu>.
Saturday, October 8, 2005, 8:31:19 PM, James Kebinger wrote:
> So what do you want?
Nothing... I have just said that your site still will not be safe after
you have prevented the calling of arbitrary Java API methods from the
templates. There are other ways of attack.
> A limit on how big one's loop variable can be? You can't prevent every
> action by a completely pathological user other than by not letting
> them upload arbitrary scripts.
And that's what I said.
--
Best regards,
Daniel Dekany
> On 10/7/05, Daniel Dekany <dd...@freemail.hu> wrote:
>>
>> Friday, October 7, 2005, 8:11:02 PM, Will Glass-Husain wrote:
>>
>> > Hi,
>> >
>> > (pls change the subject line when you change topic - thanks!)
>> >
>> > Just as a quick side note... I have hundreds of users writing their
>> Velocity
>> > own templates and uploading them to my system. You need a custom
>> > uberspector to prevent evil reflection (this will be standard in v1.6).
>> I
>> > am also cautious about what objects and methods are in the context
>> (users do
>> > not have control of this). Infinite loops are not possible with the
>> > #foreach directive.
>>
>> When I said "practically infinite loop" then I meant something like:
>>
>> #foreach( $a in [1..9999999] )
>> #foreach( $b in [1..9999999] )
>> #foreach( $c in [1..9999999] )
>> #foreach( $d in [1..9999999] )
>> #foreach( $e in [1..9999999] )
>> #foreach( $f in [1..9999999] )
>> #foreach( $g in [1..9999999] )
>> Mmmmmuhahahaha!
>> #end
>> #end
>> #end
>> #end
>> #end
>> #end
>> #end
>>
>> I would think it's a problem.
>>
>> > Finally, I use a Java security policy file for extra
>> > protection.
>> >
>> > See this essay for some more thoughts on this matter.
>> >
>> http://wiki.apache.org/jakarta-velocity/BuildingSecureWebApplications
>> >
>> > WILL
>>
>> --
>> Best regards,
>> Daniel Dekany
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> velocity-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: user-written templates / reflection safety
Posted by James Kebinger <jk...@gmail.com>.
So what do you want? A limit on how big one's loop variable can be? You
can't prevent every action by a completely pathological user other than by
not letting them upload arbitrary scripts.
On 10/7/05, Daniel Dekany <dd...@freemail.hu> wrote:
>
> Friday, October 7, 2005, 8:11:02 PM, Will Glass-Husain wrote:
>
> > Hi,
> >
> > (pls change the subject line when you change topic - thanks!)
> >
> > Just as a quick side note... I have hundreds of users writing their
> Velocity
> > own templates and uploading them to my system. You need a custom
> > uberspector to prevent evil reflection (this will be standard in v1.6).
> I
> > am also cautious about what objects and methods are in the context
> (users do
> > not have control of this). Infinite loops are not possible with the
> > #foreach directive.
>
> When I said "practically infinite loop" then I meant something like:
>
> #foreach( $a in [1..9999999] )
> #foreach( $b in [1..9999999] )
> #foreach( $c in [1..9999999] )
> #foreach( $d in [1..9999999] )
> #foreach( $e in [1..9999999] )
> #foreach( $f in [1..9999999] )
> #foreach( $g in [1..9999999] )
> Mmmmmuhahahaha!
> #end
> #end
> #end
> #end
> #end
> #end
> #end
>
> I would think it's a problem.
>
> > Finally, I use a Java security policy file for extra
> > protection.
> >
> > See this essay for some more thoughts on this matter.
> > http://wiki.apache.org/jakarta-velocity/BuildingSecureWebApplications
> >
> > WILL
>
> --
> Best regards,
> Daniel Dekany
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
Re: user-written templates / reflection safety
Posted by Daniel Dekany <dd...@freemail.hu>.
Friday, October 7, 2005, 8:11:02 PM, Will Glass-Husain wrote:
> Hi,
>
> (pls change the subject line when you change topic - thanks!)
>
> Just as a quick side note... I have hundreds of users writing their Velocity
> own templates and uploading them to my system. You need a custom
> uberspector to prevent evil reflection (this will be standard in v1.6). I
> am also cautious about what objects and methods are in the context (users do
> not have control of this). Infinite loops are not possible with the
> #foreach directive.
When I said "practically infinite loop" then I meant something like:
#foreach( $a in [1..9999999] )
#foreach( $b in [1..9999999] )
#foreach( $c in [1..9999999] )
#foreach( $d in [1..9999999] )
#foreach( $e in [1..9999999] )
#foreach( $f in [1..9999999] )
#foreach( $g in [1..9999999] )
Mmmmmuhahahaha!
#end
#end
#end
#end
#end
#end
#end
I would think it's a problem.
> Finally, I use a Java security policy file for extra
> protection.
>
> See this essay for some more thoughts on this matter.
> http://wiki.apache.org/jakarta-velocity/BuildingSecureWebApplications
>
> WILL
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: user-written templates / reflection safety
Posted by Will Glass-Husain <wg...@forio.com>.
Hi Robert,
Thanks for the note. As a side note, please see that we've switched to
JIRA - reference this issue.
http://issues.apache.org/jira/browse/VELOCITY-179
Basically, committer time and pressing deadlines. There's been a renewed
surge of activity this year (this Fall in particular) to catch up on
outstanding bugs and critical enhancements. We've designated a feature
freeze for v1.5 at the end of October. Since Velocity supports pluggable
Uberspectors (e.g. you can use this code in your own Uberspector) this
wasn't seen as a critical enhancement by that deadline. Once v1.5 is
released I'll be committing this patch first thing.
Best, WILL
----- Original Message -----
From: "Robert Koberg" <ro...@koberg.com>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: Friday, October 07, 2005 11:29 AM
Subject: Re: user-written templates / reflection safety
> Will Glass-Husain wrote:
>> Hi,
>>
>> (pls change the subject line when you change topic - thanks!)
>>
>> Just as a quick side note... I have hundreds of users writing their
>> Velocity
>> own templates and uploading them to my system. You need a custom
>> uberspector to prevent evil reflection (this will be standard in v1.6).
>> I
>> am also cautious about what objects and methods are in the context (users
>> do
>> not have control of this). Infinite loops are not possible with the
>> #foreach directive. Finally, I use a Java security policy file for extra
>> protection.
>>
>> See this essay for some more thoughts on this matter.
>> http://wiki.apache.org/jakarta-velocity/BuildingSecureWebApplications
>
> Hi Will,
>
> What is stopping the patches here (referenced from the above wiki page):
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=20341
>
> from being implemented?
>
> Are other committers against this?
>
> In my situation I do not always have the qa or prod server machine under
> my control. The server admin might be very inexperienced or know nothing
> about java let alone policy files.
>
> I think it is a great thing in velocity's favor if the packages outlined
> in the UberspectImpl.java are removed from the template author's arsenal.
>
> best,
> -Rob
>
>
>>
>> WILL
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: user-written templates / reflection safety
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Robert Koberg <ro...@koberg.com> writes:
>Hi Will,
>What is stopping the patches here (referenced from the above wiki page):
>http://issues.apache.org/bugzilla/show_bug.cgi?id=20341
>from being implemented?
>Are other committers against this?
Mainly the move to JIRA, time constraints by the developers and
(admittedly) the fact that development pace has picked up only lately
with Will devoting more time to pushing the 1.5 release out.
If you are interested in the state of developer discussion and/or patch
acceptance, you are very welcome over there at velocity-dev and our mail
archive which contains all developer discussion.
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: user-written templates / reflection safety
Posted by Robert Koberg <ro...@koberg.com>.
Will Glass-Husain wrote:
> Hi,
>
> (pls change the subject line when you change topic - thanks!)
>
> Just as a quick side note... I have hundreds of users writing their
> Velocity
> own templates and uploading them to my system. You need a custom
> uberspector to prevent evil reflection (this will be standard in v1.6). I
> am also cautious about what objects and methods are in the context
> (users do
> not have control of this). Infinite loops are not possible with the
> #foreach directive. Finally, I use a Java security policy file for extra
> protection.
>
> See this essay for some more thoughts on this matter.
> http://wiki.apache.org/jakarta-velocity/BuildingSecureWebApplications
Hi Will,
What is stopping the patches here (referenced from the above wiki page):
http://issues.apache.org/bugzilla/show_bug.cgi?id=20341
from being implemented?
Are other committers against this?
In my situation I do not always have the qa or prod server machine under
my control. The server admin might be very inexperienced or know nothing
about java let alone policy files.
I think it is a great thing in velocity's favor if the packages outlined
in the UberspectImpl.java are removed from the template author's arsenal.
best,
-Rob
>
> WILL
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
user-written templates / reflection safety
Posted by Will Glass-Husain <wg...@forio.com>.
Hi,
(pls change the subject line when you change topic - thanks!)
Just as a quick side note... I have hundreds of users writing their Velocity
own templates and uploading them to my system. You need a custom
uberspector to prevent evil reflection (this will be standard in v1.6). I
am also cautious about what objects and methods are in the context (users do
not have control of this). Infinite loops are not possible with the
#foreach directive. Finally, I use a Java security policy file for extra
protection.
See this essay for some more thoughts on this matter.
http://wiki.apache.org/jakarta-velocity/BuildingSecureWebApplications
WILL
----- Original Message -----
From: "Daniel Dekany" <dd...@freemail.hu>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: Friday, October 07, 2005 10:57 AM
> FreeMarker has support to be used with Java's security policy feature...
> but I don't know it. Anyway, my opinion abut this topic in general is
> that almost none of the template engines around was designed to be
> something that you can let written be the users (as opposed to developer
> team mates like HTML page designers). Nor FreeMarker. Yes, you can
> prevent some really evil things by not allowing unrestricted reflection
> calls. But evil users still can add a practically infinite loop and
> whatever DoS-style stuff to your templates...
----- Original Message -----
From: "Daniel Dekany" <dd...@freemail.hu>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: Friday, October 07, 2005 10:57 AM
Subject: Re: [ANN] Viento - WHY?
> Friday, October 7, 2005, 7:31:41 PM, Robert Koberg wrote:
>
>> Daniel Dekany wrote:
>>> Friday, October 7, 2005, 6:28:16 PM, jian chen wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>I have been looking at the FreeMarker vs. Velocity emails. The only
>>>>objection that I don't use FreeMarker in my project is, I prefer the
>>>>Velocity syntax to FreeMarker. I like a clear separation of the template
>>>>code from the HTML.
>>>
>>>
>>> What do you mean by that? Maybe you only know the early FM. For a while
>>> FreeMarker tags look like <#if whatever>...</#if> and <@myMacro whatever
>>> />,
>>> so they are clearly separated from the XML/HTML now.
>>
>> Yes, they are clearly not HTML or XML. But FM templates cannot be
>> written (comfortably) in an HTML or XML editor that is checking for
>> well-formedness or validity.
>
> Nor Velocity templates... for example try to conditionally add an
> attribute. That will not be even well-formed. But yes, simple templates
> can remain valid with Velocity.
>
>> The main problem for me is the syntax above would not pass through an
>> XML parser.
>
> Why do you pass trough a template (rather than it's output) an XML
> parser? I ask because I hear it a lot... if only one people needs it,
> fine. But why is this demand so popular? For what do people use this?
>
>> I realize FM has very recently added an XML freindly syntax,
>
> Well.. only as XML friendly as Velocity. Real XML friendly syntaxes are
> like Zope Template Language. But, they are terribly verbose.
>
>> but Velocity has always had it and i feel more comfortable using
>> something that has been around longer (the XML friendly syntax).
>>
>> I don't want anything else added to Velocity. I want it to stay simple
>> so only very basic things can get done in a template.
>>
>> One thing that might make me think about switching has to do with
>> security. Can you do something like this is FM:
>>
>> #set ($classLoader = $request.getClass().getClassLoader())
>>
>> ?
>
> Not by default... AFAIK nor in Velocity soon. FreeMarker is
> traditionally conservative in exposing the Java API of objects, since
> it's doesn't rely on Java's reflection API too much.
>
>> I don't want a user to be able to do this. And I do not want to have a
>> server admin to have to manage policy files to accomplish it.
>
> FreeMarker has support to be used with Java's security policy feature...
> but I don't know it. Anyway, my opinion abut this topic in general is
> that almost none of the template engines around was designed to be
> something that you can let written be the users (as opposed to developer
> team mates like HTML page designers). Nor FreeMarker. Yes, you can
> prevent some really evil things by not allowing unrestricted reflection
> calls. But evil users still can add a practically infinite loop and
> whatever DoS-style stuff to your templates...
>
>> -Rob
>
> --
> Best regards,
> Daniel Dekany
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Daniel Dekany <dd...@freemail.hu>.
Friday, October 7, 2005, 7:31:41 PM, Robert Koberg wrote:
> Daniel Dekany wrote:
>> Friday, October 7, 2005, 6:28:16 PM, jian chen wrote:
>>
>>
>>>Hi,
>>>
>>>I have been looking at the FreeMarker vs. Velocity emails. The only
>>>objection that I don't use FreeMarker in my project is, I prefer the
>>>Velocity syntax to FreeMarker. I like a clear separation of the template
>>>code from the HTML.
>>
>>
>> What do you mean by that? Maybe you only know the early FM. For a while
>> FreeMarker tags look like <#if whatever>...</#if> and <@myMacro whatever />,
>> so they are clearly separated from the XML/HTML now.
>
> Yes, they are clearly not HTML or XML. But FM templates cannot be
> written (comfortably) in an HTML or XML editor that is checking for
> well-formedness or validity.
Nor Velocity templates... for example try to conditionally add an
attribute. That will not be even well-formed. But yes, simple templates
can remain valid with Velocity.
> The main problem for me is the syntax above would not pass through an
> XML parser.
Why do you pass trough a template (rather than it's output) an XML
parser? I ask because I hear it a lot... if only one people needs it,
fine. But why is this demand so popular? For what do people use this?
> I realize FM has very recently added an XML freindly syntax,
Well.. only as XML friendly as Velocity. Real XML friendly syntaxes are
like Zope Template Language. But, they are terribly verbose.
> but Velocity has always had it and i feel more comfortable using
> something that has been around longer (the XML friendly syntax).
>
> I don't want anything else added to Velocity. I want it to stay simple
> so only very basic things can get done in a template.
>
> One thing that might make me think about switching has to do with
> security. Can you do something like this is FM:
>
> #set ($classLoader = $request.getClass().getClassLoader())
>
> ?
Not by default... AFAIK nor in Velocity soon. FreeMarker is
traditionally conservative in exposing the Java API of objects, since
it's doesn't rely on Java's reflection API too much.
> I don't want a user to be able to do this. And I do not want to have a
> server admin to have to manage policy files to accomplish it.
FreeMarker has support to be used with Java's security policy feature...
but I don't know it. Anyway, my opinion abut this topic in general is
that almost none of the template engines around was designed to be
something that you can let written be the users (as opposed to developer
team mates like HTML page designers). Nor FreeMarker. Yes, you can
prevent some really evil things by not allowing unrestricted reflection
calls. But evil users still can add a practically infinite loop and
whatever DoS-style stuff to your templates...
> -Rob
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Restricting method invokation (was: Re: [ANN] Viento - WHY?)
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Robert Koberg <ro...@koberg.com> writes:
[ I process this thread now strictly read-only. If I find something
that is at least remotely Velocity related and want to write something
about it, I will change the subject. So there might at least get some
constructive work from this thread. :-) ]
>One thing that might make me think about switching has to do with
>security. Can you do something like this is FM:
>#set ($classLoader = $request.getClass().getClassLoader())
AFAIK, some methods are either blocked or you can turn method blocking
on. There is a list of methods in
src/freemarker/ext/beans/unsafeMethods.txt which lists methods that
are considered dangerous. I might argue about some of them, but at
least the various getClassLoader() and Class.forName() are in there.
Adding security is a good idea and Will is talking about implementing
method invocation restrictions. ATM, FreeMarker has here more
functionality than Velocity.
If we do this, we will try to do it in a way that there is no penalty
for users who does not need it (and be honest: How big is the
percentage of applications that actually allow 3rd party users to
upload templates to a web applications? Because that is the problem
domain. If you impose a penalty on method invocation on all
applications that use a templating engine, you will end up with a
slower solution because of the overhead).
Side note: Until Wills' talk about Hacking Velocity @ AC'04,
personally I had no idea that this is possible in Velocity. :-) But
then again I never had a case that users were allowed to upload
Templates to an application of mine.
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Robert Koberg <ro...@koberg.com>.
Daniel Dekany wrote:
> Friday, October 7, 2005, 6:28:16 PM, jian chen wrote:
>
>
>>Hi,
>>
>>I have been looking at the FreeMarker vs. Velocity emails. The only
>>objection that I don't use FreeMarker in my project is, I prefer the
>>Velocity syntax to FreeMarker. I like a clear separation of the template
>>code from the HTML.
>
>
> What do you mean by that? Maybe you only know the early FM. For a while
> FreeMarker tags look like <#if whatever>...</#if> and <@myMacro whatever />,
> so they are clearly separated from the XML/HTML now.
Yes, they are clearly not HTML or XML. But FM templates cannot be
written (comfortably) in an HTML or XML editor that is checking for
well-formedness or validity.
The main problem for me is the syntax above would not pass through an
XML parser. I realize FM has very recently added an XML freindly syntax,
but Velocity has always had it and i feel more comfortable using
something that has been around longer (the XML friendly syntax).
I don't want anything else added to Velocity. I want it to stay simple
so only very basic things can get done in a template.
One thing that might make me think about switching has to do with
security. Can you do something like this is FM:
#set ($classLoader = $request.getClass().getClassLoader())
? I don't want a user to be able to do this. And I do not want to have a
server admin to have to manage policy files to accomplish it.
-Rob
>
>
>>Just my 2 cents,
>>
>>Cheers,
>>
>>Jian
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Daniel Dekany <dd...@freemail.hu>.
Friday, October 7, 2005, 6:28:16 PM, jian chen wrote:
> Hi,
>
> I have been looking at the FreeMarker vs. Velocity emails. The only
> objection that I don't use FreeMarker in my project is, I prefer the
> Velocity syntax to FreeMarker. I like a clear separation of the template
> code from the HTML.
What do you mean by that? Maybe you only know the early FM. For a while
FreeMarker tags look like <#if whatever>...</#if> and <@myMacro whatever />,
so they are clearly separated from the XML/HTML now.
> Just my 2 cents,
>
> Cheers,
>
> Jian
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Michael Heuer <he...@acm.org>.
Hello,
I have also been looking at the FreeMarker vs. Velocity emails.
This is the Velocity users list. Take it elsewhere, please.
michael
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by jian chen <ch...@gmail.com>.
Hi,
I have been looking at the FreeMarker vs. Velocity emails. The only
objection that I don't use FreeMarker in my project is, I prefer the
Velocity syntax to FreeMarker. I like a clear separation of the template
code from the HTML.
Just my 2 cents,
Cheers,
Jian
On 10/7/05, Jonathan Revusky <re...@wanadoo.es> wrote:
>
> Malcolm Edgar wrote:
> > All good stuff..
> >
> > FreeMaker is pretty cool, however I ended up using Velocity because of
> its
> > simplicity and because the Velocity directives don't look like xml/html:
> >
> > http://click.sourceforge.net/docs/faq.html#why-velocity
>
> Well, you're certainly free to opt for whatever tools you like. Also,
> the existence of FreeMarker, even if you choose not to use it (for now
> at least :-)) only gives you more options. (Also, FM's existence and
> continued development puts some pressure on the Velocity developers to
> get their act together, which benefits you and other Velocity users.)
>
> Anyway, as regards your link above, I had come across that in various
> web surfing/googling and had a few comments that I intended to make, but
> never got around to it.
>
> In the above linked page, you point out (correctly) that FreeMarker
> clearly has better error reporting than Velocity. (For example, this was
> one of the reasons cited by the Webwork people for their migration.)
> However, you then provide examples of how your Click framework mitigates
> that.
>
> You provide a link to the following error page provided by your framework.
>
> http://click.sourceforge.net/docs/error-npe.html
>
> Now, I think this kind of does beg the question a bit. Most of the time
> you have a null pointer sort of problem in the template engine space is
> when somebody misspells the name of a variable in some way. They write:
>
> ${user.first_name}
>
> when it should be:
>
> ${user.firstName}
>
> or vice versa or whatever. And in general, people are not very good
> spellers for the most part and it's very easy to make such mistakes.
>
> But when somebody on the template level makes such a mistake, what good
> does it do that person to get a java stack trace? Surely what they need
> is the line number location in the template file where the mistake was
> made.
>
> Software is built in many layers and people are typically working on a
> given layer and other people on another layer, and thus, a division of
> labor is achieved.
>
> By analogy, if I try to reference a null in java code, but get a stack
> trace showing me where the problem was triggered in the underlying C
> code in the JVM, how useful would this be for me as a java programmer
> working on that layer? I am working at one layer (the java code) and it
> is giving me an error message wrt another, lower layer (the C code in
> the JVM.)
>
> Surely you see my point, right? Meanwhile, by way of contrast to the
> error page from Click that you show above, here is what a similar error
> message from FreeMarker outputs:
>
> Expression foobar is undefined on line 2, column 3 in bar.ftl.
> The problematic instruction:
> ----------
> ==> ${foobar} [on line 2, column 1 in bar.ftl]
> in include "bar.ftl" [on line 2, column 1 in foo.ftl]
> ----------
>
> Java backtrace for programmers:
> ----------
> freemarker.core.InvalidReferenceException: Expression foobar is
> undefined on line 2, column 3 in bar.ftl.
> at
> freemarker.core.TemplateObject.assertNonNull(TemplateObject.java:124)
> at freemarker.core.Expression.getStringValue(Expression.java:118)
> at freemarker.core.Expression.getStringValue(Expression.java:93)
> at freemarker.core.DollarVariable.accept(DollarVariable.java:76)
> at freemarker.core.Environment.visit(Environment.java:196)
> at freemarker.core.MixedContent.accept(MixedContent.java:92)
> at freemarker.core.Environment.visit(Environment.java:196)
> at freemarker.core.Environment.include(Environment.java:1365)
> at freemarker.core.Include.accept(Include.java:155)
> at freemarker.core.Environment.visit(Environment.java:196)
> at freemarker.core.MixedContent.accept(MixedContent.java:92)
> at freemarker.core.Environment.visit(Environment.java:196)
> at freemarker.core.Environment.process(Environment.java:176)
> at freemarker.template.Template.process(Template.java:231)
> <etcetera>
>
>
> You see my point, I'm sure. The error message tells the template writer
> where the error occurred *at the level he or she is working at*, i.e.
> the line/column information in the template file. (And, of course, it
> does provide the java stack trace that could be copy/pasted in an email
> to the java developers, if necessary.)
>
> Now, I grant that using your framework probably does offer substantial
> advantages over using Velocity alone -- in this and other regards.
> However, to imply that it fully addresses the error reporting problems
> inherent in Velocity (as compared to FreeMarker) is clearly incorrect.
>
> Since you did basically bring this up by pointing to this link, I think
> it is only proper that I should point this out.
>
> Regards,
>
> Jonathan Revusky
> --
> lead developer, FreeMarker project, http://freemarker.org/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
Re: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Malcolm Edgar wrote:
> All good stuff..
>
> FreeMaker is pretty cool, however I ended up using Velocity because of its
> simplicity and because the Velocity directives don't look like xml/html:
>
> http://click.sourceforge.net/docs/faq.html#why-velocity
Well, you're certainly free to opt for whatever tools you like. Also,
the existence of FreeMarker, even if you choose not to use it (for now
at least :-)) only gives you more options. (Also, FM's existence and
continued development puts some pressure on the Velocity developers to
get their act together, which benefits you and other Velocity users.)
Anyway, as regards your link above, I had come across that in various
web surfing/googling and had a few comments that I intended to make, but
never got around to it.
In the above linked page, you point out (correctly) that FreeMarker
clearly has better error reporting than Velocity. (For example, this was
one of the reasons cited by the Webwork people for their migration.)
However, you then provide examples of how your Click framework mitigates
that.
You provide a link to the following error page provided by your framework.
http://click.sourceforge.net/docs/error-npe.html
Now, I think this kind of does beg the question a bit. Most of the time
you have a null pointer sort of problem in the template engine space is
when somebody misspells the name of a variable in some way. They write:
${user.first_name}
when it should be:
${user.firstName}
or vice versa or whatever. And in general, people are not very good
spellers for the most part and it's very easy to make such mistakes.
But when somebody on the template level makes such a mistake, what good
does it do that person to get a java stack trace? Surely what they need
is the line number location in the template file where the mistake was made.
Software is built in many layers and people are typically working on a
given layer and other people on another layer, and thus, a division of
labor is achieved.
By analogy, if I try to reference a null in java code, but get a stack
trace showing me where the problem was triggered in the underlying C
code in the JVM, how useful would this be for me as a java programmer
working on that layer? I am working at one layer (the java code) and it
is giving me an error message wrt another, lower layer (the C code in
the JVM.)
Surely you see my point, right? Meanwhile, by way of contrast to the
error page from Click that you show above, here is what a similar error
message from FreeMarker outputs:
Expression foobar is undefined on line 2, column 3 in bar.ftl.
The problematic instruction:
----------
==> ${foobar} [on line 2, column 1 in bar.ftl]
in include "bar.ftl" [on line 2, column 1 in foo.ftl]
----------
Java backtrace for programmers:
----------
freemarker.core.InvalidReferenceException: Expression foobar is
undefined on line 2, column 3 in bar.ftl.
at
freemarker.core.TemplateObject.assertNonNull(TemplateObject.java:124)
at freemarker.core.Expression.getStringValue(Expression.java:118)
at freemarker.core.Expression.getStringValue(Expression.java:93)
at freemarker.core.DollarVariable.accept(DollarVariable.java:76)
at freemarker.core.Environment.visit(Environment.java:196)
at freemarker.core.MixedContent.accept(MixedContent.java:92)
at freemarker.core.Environment.visit(Environment.java:196)
at freemarker.core.Environment.include(Environment.java:1365)
at freemarker.core.Include.accept(Include.java:155)
at freemarker.core.Environment.visit(Environment.java:196)
at freemarker.core.MixedContent.accept(MixedContent.java:92)
at freemarker.core.Environment.visit(Environment.java:196)
at freemarker.core.Environment.process(Environment.java:176)
at freemarker.template.Template.process(Template.java:231)
<etcetera>
You see my point, I'm sure. The error message tells the template writer
where the error occurred *at the level he or she is working at*, i.e.
the line/column information in the template file. (And, of course, it
does provide the java stack trace that could be copy/pasted in an email
to the java developers, if necessary.)
Now, I grant that using your framework probably does offer substantial
advantages over using Velocity alone -- in this and other regards.
However, to imply that it fully addresses the error reporting problems
inherent in Velocity (as compared to FreeMarker) is clearly incorrect.
Since you did basically bring this up by pointing to this link, I think
it is only proper that I should point this out.
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Malcolm Edgar <ma...@gmail.com>.
All good stuff..
FreeMaker is pretty cool, however I ended up using Velocity because of its
simplicity and because the Velocity directives don't look like xml/html:
http://click.sourceforge.net/docs/faq.html#why-velocity
cheers Malcolm
On 10/7/05, Jonathan Revusky <re...@wanadoo.es> wrote:
>
> Steve O'Hara wrote:
> > Am I missing something here......??
> >
> > There seems to be a whole load of template laguages springing up all
> > over the place that look very similar to Velocity, each claiming it
> > solves a view problem that Velocity doesn't.
>
> Actually, I'm not aware of an inordinate number of template engine
> projects coming on-line. What I mostly see is a huge number of MVC web
> frameworks.
>
> >
> > I've always assumed that Velocity is a "work in progress" and
> > contributions from programmers that improve it are always welcome.
>
> Well, yeah, that's the theory..... BUT it's basically an open secret
> taht the Velocity project has been dysfunctional for a long period of
> time. There has been some attempt recently (mostly from Will
> Glass-Husain) to re-animate things but the judgment is still out as to
> how successful that will be. For example, the map literal thing that has
> come up in this list, a patch was donated for that in 2002 or so and
> simply ignored. I guess Will has finally addressed the issue 3 years
> later. He apparently recently fixed a bug where you couldn't write
> velocity directives on multiple lines. But this must have been in the
> bug tracker literally for years. Also, it is IMO an amazing kind of bug
> to persist for periods of years. Surely, the fix was utterly trivial.
>
> So, obviously, if somebody offered a patch or bug reports and they were
> ignored, their tendency to bother at a later stage would not be so
> great. Rational people want to invest their energies where they will see
> results, don't they? The Velocity project, for most of the past 3 years
> or so, has not bee such a place. So this could explain people's tendency
> to invest their time and energy elsewhere.
>
>
> > So
> > why aren't these FreeMarker/Viento/TomDick&Harry developers contributing
> > to Velocity rather than creating yet another clone?
>
> Well, I can't speak for Adam Williams and the other developers of
> Viento, but regarding FreeMarker, you seem to suffer from the
> misconception that FreeMarker is some kind of "me too" Velocity
> knock-off. That is almost 180º away from the reality of things.
>
> FreeMarker actually predates Velocity, having been around since early
> 1999. FreeMarker and Webmacro were really the pioneering java template
> engines of the time. Velocity was later created more or less as a
> Webmacro knock-off in 2000. Of course, it later gained a significantly
> larger user base than the pioneering projects, FM and WM, because of the
> visibility advantage of being on apache.org <http://apache.org>.
>
> >
> > I don't have any axe to grind either way but it seems a little odd to
> > keep developing new code bases for essentailly the same thing.
>
> Your comments are actually quite ironic when one considers the early
> history of the Velocity project.
>
> > I'm all
> > for step changed developments, but as far as I can make out, most of
> > these other tools are just slight improvements on the original.
>
> Have you performed a dilligent comparative evaluation of Velocity and
> FreeMarker and come to that conclusion?
>
> Certainly, other professionals in this field have come to a different
> conclusion.
>
>
> http://blog.nominet.org.uk/tech/Web/2005/06/29/Switching+from+Velocity+to+FreeMarker.html
>
> Or consider the comments by Aleksei Gopachenko and Ken Egervari in the
> following blog entry.
>
> http://jroller.com/comments/raible/home/freemarker_vs_velocity
>
> Both were long-time Velocity users who switched to FreeMarker. Their
> considered view is that the differences much more than "slight
> improvements".
>
> The Webwork people recently decided to switch from Velocity to
> FreeMarker as their default template engine and this is another weblog
> entry of a web development professional relating that he was switching
> all development over to FreeMarker.
>
>
> http://jroller.com/page/webwork2live?anchor=switch_to_freemarker_from_velocity
>
> Surely, if FreeMarker only offered "slight improvements" people wouldn't
> bother to undertake such a migration, would they?
>
> >
> > Can anyone enlighten me?
>
> Well, I hope the above comments about history and other links are
> enlightening. Of course, you will take into account that the source of
> them is necessarily somewhat biased. :-)
>
> Regards,
>
> Jonathan Revusky
> --
> lead developer, FreeMarker project, http://freemarker.org/
>
> >
> > Steve
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
Re: [ANN] Viento - WHY?
Posted by Jonathan Revusky <re...@wanadoo.es>.
Steve O'Hara wrote:
> Am I missing something here......??
>
> There seems to be a whole load of template laguages springing up all
> over the place that look very similar to Velocity, each claiming it
> solves a view problem that Velocity doesn't.
Actually, I'm not aware of an inordinate number of template engine
projects coming on-line. What I mostly see is a huge number of MVC web
frameworks.
>
> I've always assumed that Velocity is a "work in progress" and
> contributions from programmers that improve it are always welcome.
Well, yeah, that's the theory..... BUT it's basically an open secret
taht the Velocity project has been dysfunctional for a long period of
time. There has been some attempt recently (mostly from Will
Glass-Husain) to re-animate things but the judgment is still out as to
how successful that will be. For example, the map literal thing that has
come up in this list, a patch was donated for that in 2002 or so and
simply ignored. I guess Will has finally addressed the issue 3 years
later. He apparently recently fixed a bug where you couldn't write
velocity directives on multiple lines. But this must have been in the
bug tracker literally for years. Also, it is IMO an amazing kind of bug
to persist for periods of years. Surely, the fix was utterly trivial.
So, obviously, if somebody offered a patch or bug reports and they were
ignored, their tendency to bother at a later stage would not be so
great. Rational people want to invest their energies where they will see
results, don't they? The Velocity project, for most of the past 3 years
or so, has not bee such a place. So this could explain people's tendency
to invest their time and energy elsewhere.
> So
> why aren't these FreeMarker/Viento/TomDick&Harry developers contributing
> to Velocity rather than creating yet another clone?
Well, I can't speak for Adam Williams and the other developers of
Viento, but regarding FreeMarker, you seem to suffer from the
misconception that FreeMarker is some kind of "me too" Velocity
knock-off. That is almost 180º away from the reality of things.
FreeMarker actually predates Velocity, having been around since early
1999. FreeMarker and Webmacro were really the pioneering java template
engines of the time. Velocity was later created more or less as a
Webmacro knock-off in 2000. Of course, it later gained a significantly
larger user base than the pioneering projects, FM and WM, because of the
visibility advantage of being on apache.org.
>
> I don't have any axe to grind either way but it seems a little odd to
> keep developing new code bases for essentailly the same thing.
Your comments are actually quite ironic when one considers the early
history of the Velocity project.
> I'm all
> for step changed developments, but as far as I can make out, most of
> these other tools are just slight improvements on the original.
Have you performed a dilligent comparative evaluation of Velocity and
FreeMarker and come to that conclusion?
Certainly, other professionals in this field have come to a different
conclusion.
http://blog.nominet.org.uk/tech/Web/2005/06/29/Switching+from+Velocity+to+FreeMarker.html
Or consider the comments by Aleksei Gopachenko and Ken Egervari in the
following blog entry.
http://jroller.com/comments/raible/home/freemarker_vs_velocity
Both were long-time Velocity users who switched to FreeMarker. Their
considered view is that the differences much more than "slight
improvements".
The Webwork people recently decided to switch from Velocity to
FreeMarker as their default template engine and this is another weblog
entry of a web development professional relating that he was switching
all development over to FreeMarker.
http://jroller.com/page/webwork2live?anchor=switch_to_freemarker_from_velocity
Surely, if FreeMarker only offered "slight improvements" people wouldn't
bother to undertake such a migration, would they?
>
> Can anyone enlighten me?
Well, I hope the above comments about history and other links are
enlightening. Of course, you will take into account that the source of
them is necessarily somewhat biased. :-)
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
> Steve
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [ANN] Viento - WHY?
Posted by Malcolm Edgar <ma...@gmail.com>.
Well, I dont think this is a bad thing.
The richness and diversity of the OS world is one if its key strengths.
FreeMarker for example is a more sophisticated templating language than
Velocity, and is probably better suited for some problem domains than
Velocity.
There is a healthy exhange of ideas in the OS world. Yes there is obviously
a lot of wasted effort, but sometimes you dont know what you will end up
with until you give it a go.
regards Malcolm Edgar
On 10/6/05, Andrew Mason <an...@assertis.co.uk> wrote:
>
> I kind of agree, especially when velocity seems to solve a whole bunch of
> problems that these new engines have.
>
> Also, the documentation for velocity is already there and quite good, a
> large
> userbase is set up and from what i've seen of the velocity code, its quite
> clean and I at least found it easy to understand.
> *shrug*
>
> On Thu October 6 2005 12:31 pm, Steve O'Hara wrote:
> > Am I missing something here......??
> >
> > There seems to be a whole load of template laguages springing up all
> > over the place that look very similar to Velocity, each claiming it
> > solves a view problem that Velocity doesn't.
> >
> > I've always assumed that Velocity is a "work in progress" and
> > contributions from programmers that improve it are always welcome. So
> > why aren't these FreeMarker/Viento/TomDick&Harry developers contributing
> > to Velocity rather than creating yet another clone?
> >
> > I don't have any axe to grind either way but it seems a little odd to
> > keep developing new code bases for essentailly the same thing. I'm all
> > for step changed developments, but as far as I can make out, most of
> > these other tools are just slight improvements on the original.
> >
> > Can anyone enlighten me?
> >
> > Steve
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From:
> > velocity-user-return-16791-sohara=pivotal-solutions.co.uk@jakarta.apache
> > .org
> > [mailto:velocity-user-return-16791-sohara=pivotal-solutions.co.uk@jakart
> > a.apache.org <http://a.apache.org>] On Behalf Of Adam Williams
> > Sent: 06 October 2005 04:41
> > To: Velocity Users List
> > Subject: [ANN] Viento
> >
> > Hello.
> >
> > Velocity is great. It can be used to template anything, and works
> > quite well. Well, except for inline Maps ;) We have been using it for
> > almost three years, and would never go back to JSP, JSF, or
> > String.format().
> >
> > Alas, we have needs that it cannot meet. The Sails[1] Web2.0 Solution
> > is under refinement, part of which required a new template language:
> > extensibility built into the design, Java 1.5, blocks. It is called
> > Viento[2].
> >
> > Since you folks know template languages real well, the Sails team
> > hopes that you might do us a favor. Check out Viento and let us know
> > what you think. Read up on it, browse the source, and catch the
> > Wind[3].
> >
> > adam williams
> > creator, Sails
> >
> > austin taylor
> > creator, Viento
> >
> >
> >
> > [1] http://www.opensails.org
> > [2] http://www.opensails.org/sails/wiki/Viento
> > [3] Viento is a Spanish word meaning 'Wind' - the kind that moves
> > sailboats
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
Re: [ANN] Viento - WHY?
Posted by Andrew Mason <an...@assertis.co.uk>.
I kind of agree, especially when velocity seems to solve a whole bunch of
problems that these new engines have.
Also, the documentation for velocity is already there and quite good, a large
userbase is set up and from what i've seen of the velocity code, its quite
clean and I at least found it easy to understand.
*shrug*
On Thu October 6 2005 12:31 pm, Steve O'Hara wrote:
> Am I missing something here......??
>
> There seems to be a whole load of template laguages springing up all
> over the place that look very similar to Velocity, each claiming it
> solves a view problem that Velocity doesn't.
>
> I've always assumed that Velocity is a "work in progress" and
> contributions from programmers that improve it are always welcome. So
> why aren't these FreeMarker/Viento/TomDick&Harry developers contributing
> to Velocity rather than creating yet another clone?
>
> I don't have any axe to grind either way but it seems a little odd to
> keep developing new code bases for essentailly the same thing. I'm all
> for step changed developments, but as far as I can make out, most of
> these other tools are just slight improvements on the original.
>
> Can anyone enlighten me?
>
> Steve
>
>
>
>
>
> -----Original Message-----
> From:
> velocity-user-return-16791-sohara=pivotal-solutions.co.uk@jakarta.apache
> .org
> [mailto:velocity-user-return-16791-sohara=pivotal-solutions.co.uk@jakart
> a.apache.org] On Behalf Of Adam Williams
> Sent: 06 October 2005 04:41
> To: Velocity Users List
> Subject: [ANN] Viento
>
> Hello.
>
> Velocity is great. It can be used to template anything, and works
> quite well. Well, except for inline Maps ;) We have been using it for
> almost three years, and would never go back to JSP, JSF, or
> String.format().
>
> Alas, we have needs that it cannot meet. The Sails[1] Web2.0 Solution
> is under refinement, part of which required a new template language:
> extensibility built into the design, Java 1.5, blocks. It is called
> Viento[2].
>
> Since you folks know template languages real well, the Sails team
> hopes that you might do us a favor. Check out Viento and let us know
> what you think. Read up on it, browse the source, and catch the
> Wind[3].
>
> adam williams
> creator, Sails
>
> austin taylor
> creator, Viento
>
>
>
> [1] http://www.opensails.org
> [2] http://www.opensails.org/sails/wiki/Viento
> [3] Viento is a Spanish word meaning 'Wind' - the kind that moves
> sailboats
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org