velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Heyl <...@pixelboxx.de>
Subject Re: velocity macro #exit feature
Date Fri, 16 Jul 2004 15:56:43 GMT
chenjian wrote:

>Hi,
>  
>
Ho,

>I have some counter views about not adding #return to the macro.
>
>1) Most developers are familar with return statement in any programming 
>language, and the most intuitive solution is to provide a #return.
>  
>
A template language is not and should be a  general purpose programming 
language.
That's the way to JSP and missing separation of concerns (eg. MVC-like 
separation), application logic inside templates.
Been there, lesson learned, dumped jsp and found velocity to be good enough.
A template language should stick to it's purpose and provide a useful 
text preparation language.
Velocity has it's weaknesses with $-escaping and variable handling but 
that's another story.

>2) Talking about macro logic, it reminds me about the story for "doing the 
>right thing". For any of you who haven't heard about it, the short story is 
>here.
>
>The MIT guys built their AI operating system based on their philosophy that 
>one should do the right thing. The New Jersey guys built the C/Unix operating 
>system based on more pratical and simple solution. The result turned out that 
>C/UNIX won because it adapted to good software engineering practice. The "do 
>the right thing" MIT guys built an operating system that is hard to use, and 
>too complicated.
>
>So, the moral of the story here is that we should follow good software 
>engineering practice in our design. We are building software systems that are 
>used by normal users. And typically, normal users don't like convoluted 
>solutions.
>  
>
And so C  started  to become the language  of the internet promoting 
sandbox programming,
gargabe collection, write-once-run-anywhere, abstract data types, main 
language for scientific applications (fortran isn't dead ...),
main language for business applications (some people use velocity to 
generate cobol programs) ...
 I must have missed something.
So the moral is simple: Use the best tool to do the job.
I'm glad Mr. Gosling didn't include multiple inheritance into java just 
because C++-Programmers
were familiar with it.
But that does lead us nowhere.

Velocity is a tool to solve specific problems: Create text from 
templates based on
flags, some logic and values. These templates should be easy to write 
and to maintain.
The template language should encourage people to do things right without 
getting in the way.

A lot (most?) people use velocity for preparing structured output 
languages (html, xml)
Properly nesting of elements is the key to success here.
So just make sure each block of control ends what it started (<table> 
...</table>) and
one major source of trouble is out of the way.
Without "#return" one can be SURE  that  a macro, no matter  how long it 
is and without
reading the whole mess inside that the first line of the macro will be 
the first line of output
and the last line will be the last line of output.
Use proper nesting of large structures inside #foreach, #if, #else and 
nesting will be ok.

When "#return" is present the situation changes. I have to actually READ 
all of the macro code
to find out where some lazy or bored time worker decided to take the 
fast way out.

As others pointed out, the is no NEED for #return.

Instead of
#macro (normally-do-alot-of-work $param)
#if (exceptionalCase($param))
   #return
#end
#end

you can write:
#macro (normally-do-alot-of-work $param)
#if (!exceptionalCase($param))
   #do-alot-of-work($param)
#end
#end

but I woiuld suggest:
#macro (normally-do-alot-of-work $param)
#if (normalCase($param))
   #do-alot-of-work($param)
#end
#end

#macro (do-alot-of-work $param)
...
#end

Don't force a good language to become worse just because sticking with 
bad habits and
refusing to learn new ways.

>To summarize, I don't see why a simple #return will ruin the whole beauty of 
>the template engine. Because simply by using template engine, we already 
>restricted using Java directly in the presentation layer.
>  
>
OK, java access is somewhat restricted. Not enough to make velocity 
secure for
use in environments where access to web server JVM is to be restricted, 
but enough for
standard use. But just restricting java access does not make sure people
write maintainable macros. We are dealing with partners customizing the 
web GUI
of our software which is highly configurable. So maintenance is of major 
importance to us to make easy updates possible.
Positive inclusion of fragments/macros based on a simple positive logic 
(hasFeature(XXX), isRole(YYY) ...)
is a proved way to structure gui-templates for us.
"#return" for "exceptional cases" is "negative logic".
It's far more easy to combine multiple positive cases compared to 
negative logic.

But since velocity is easy to enhance with new features and features 
need not be activated, make an extension,
spread it to the people but PLEASE don't market it as a good way to 
produce maintainable templates.

>Jian
>
>  
>
>>===== Original Message From Carsten Heyl <cal@pixelboxx.de> =====
>>My $0.02 to the velocity maintainers:
>>
>>Please don't add something like this to the velocity standard code.
>>
>>Velocity has two major strengths:
>>   1. it's a "macro language", thats means "replacing text"
>>   2. it's simple
>>
>>"return" oder "exit" is a control flow statement from procedural
>>programming and does not belong in a macro language inside a macro
>>definition.
>>Think of a macro  as a template  with placeholders for the arguments.
>>Expanding the macro should'nt be much more than replacing the formal
>>arguments
>>with actual parameters. That's not totally true for velocity because of
>>it's parameter evaluation but IMHO that's tolerable.
>>"return" or "exit" would totally break this model  and open up the way
>>to more control flow decisions in velocity which leads to jsp, php, etc.
>>
>>Please keep velocity simple!
>>
>>There are alternatives for the "special case" shown by others on the list.
>>
>>IMHO velocity templates come to it's best using some simple loops
>>and some boolean flags, complex case decisions are done in java code and
>>velocity just enables/disables template parts.
>>Avoiding "#else" is a good thing. Name your cases and include code based
>>on these cases.
>>
>>Before trying to "improve" velocity please make yourself familiar with
>>template languages.
>>I strongly recommend a look a stringtemplate
>>(http://www.stringtemplate.org/) and especially
>>* Enforcing Model-View Separation in Template Engines*
>><http://www.cs.usfca.edu/%7Eparrt/papers/mvc.templates.pdf>.
>>(http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf)
>>for a classification of template languages and consequences.
>>Both are written by Terence Parr, the author of LL-Grammars and ANTLR, a
>>man who definitely knows grammars and
>>programming languages.
>>
>>
>>
>>chenjian@uvic.ca wrote:
>>
>>    
>>
>>>Hi, All,
>>>
>>>This question is similar to the one for adding a #exit to velocity
>>>template, but, I think maybe more difficult to add this feature. Anyway,
>>>here is my problem.
>>>
>>>I am writing a macro and I want to do something like:
>>>
>>>## check for a special case
>>>#if (false)
>>>#exit
>>>#end
>>>
>>>## general cases, do processing
>>>...
>>>
>>>Without the #exit feature in the macro, I have to do put all my general
>>>cases into a #else statement, which is a lot of indenting, since in the
>>>general cases, there are also lot of if else statements.
>>>
>>>Is it very easy to add the exit feature to velocity macro and could anyone
>>>let me know how to do it?
>>>
>>>Thanks a lot,
>>>
>>>Jian
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>      
>>>
>>--
>> Carsten Heyl				cal@pixelboxx.de
>> Pixelboxx GmbH			http://www.pixelboxx.de/
>> Ostenhellweg 56-58			Tel.:   +49 231 53 46 30
>>D-44135 Dortmund
>>
>>
>>---------------------------------------------------------------------
>>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
>
>  
>


-- 
  Carsten Heyl				cal@pixelboxx.de
  Pixelboxx GmbH			http://www.pixelboxx.de/
  Ostenhellweg 56-58			Tel.:   +49 231 53 46 30
D-44135 Dortmund


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Mime
View raw message