I believe firmly in not compromising the simplicity of VTL at the
expense of additional functionality, and I think it's great that non-
programmers can be productive in it. I believe that all the changes I
have proposed or implemented are consistent with that. However, there
are also sophisticated users of Velocity, I hope, that can make use of
the additional control, and with the additional control make VTL
templates more readable and maintainable. I think these two uses of
Velocity can easily coexist.
On Feb 17, 2009, at 15:16 , matthijs lambooy wrote:
I agree with Nathan
The simplicity of the VTL syntax has major importance for us since
non programmers can easily
understand the syntax. Please keep it as simple as possible.
Matthijs
Nathan Bubna (JIRA) wrote:
[ https://issues.apache.org/jira/browse/VELOCITY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674366
#action_12674366 ]
Nathan Bubna commented on VELOCITY-700:
---------------------------------------
-1 no labels. keep VTL simple, please. it's not java, nor should
it be. the ease of teaching it and reading it are important to
me. FYI, i'm also still considering vetoing the #foreach( $user
in $users index $i ) syntax, since i think it is ugly, unclear, and
unnecessary. the more i look at it, the more i dislike it. having
that syntax in combo with this one would make my eyes water.
(please bear with my grumpy bluntness; i like you, i'm just very
concerned about syntax choices.)
if you really feel it is necessary to control the break level,
there is always the LoopTool in velocity tools. yes, that's not
that pretty either, but that is part of the point of
VelocityTools. keep ugly, but sometimes desirable features out of
the core.
if you really feel it is important to have some better break
control in the core, let's discuss other ways. like perhaps an
optional integer argument for #break, to indicate how many levels
to break out of. Something like that would at least avoid
"uglifying" the #foreach syntax, for an unnecessary feature.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
