velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brad Cox <>
Subject Re: Can I write a macro that can call itself?
Date Fri, 13 Jul 2001 21:57:58 GMT
At 11:37 PM -0400 7/12/01, Geir Magnusson Jr. wrote:
>'info architect'? :)

What term do you prefer? I've heard html coders, user interface 
designers, bloggers....

>That sounds like the same approach Lutris' XMLC takes...  there are
>enough lurkers on this list with XMLC expertise to comment...

Thanks for the pointer. I'll check that out.

>Any chance of providing real numbers to document speed, size and
>security?  Where does the security come from?  With a Model2 pattern,
>the security is guaranteed by the front controller...

That's a criticism of JSP, not velocity. Compilers on deployment 
servers is a no no.

>Compile-time type-checking is at best a preference.  Velocity provides
>the ability for data objects to simply support the appropriate methods -
>strict type has nothing to do with it - and that is determined at run
>time.  A useful feature, I claim...

There are huge differences between static and dynamic binding; when 
types are checked to name only one. The preference issue is true; 
some prefer type errors to go unreported to show up in the running 
code which is Velocity's approach. True, Velocity handles this nicely 
by displaying the error as $varname in the browser. But catching them 
at compile time is an equally valid approach, and typically a more 
robust one.

>How does this work out for deployment?  How do you know if all the
pieces made it to the production server?

The only solutions I know are zip, war, tar, or jar files.

>JWAA is similar to JSP, but it differs from either by
>  > working entirely at compile time.
>Then there is no dynamicism to the structure of the page at runtime?
>What I mean is, since you seem to imply that at compile time all
>decisions are made regarding the structure of the view output, then it
>appears I must either  produce N different 'pages' in JAWA to correspond
>to N decisions I can make about layout, or not bother.
>How would you 'skin' - making a choice about page body at runtime based
>on user or other instance information?

This is an example of a problem that may require a dynamic approach, 
although I've not given it much thought to see whether a static 
approach couldn't be used here too. Many problems do not. In 
particular, the JWAA demo application doesn't require it, and the 
demo is typical of every web application I've ever seen or used.

>  > Since the html and java code are combined at compile time, html
>>  designers must be trained to type make, and the servlet engine must
>>  be configured to reload the changed class files. Since errors are
>>  detected at compile time, html designers must be trained to handle
>>  compilation errors in their code.
>This is a plus?

No. Just pointing out the tradeoff. Every alternative has tradeoffs.

>  > Alternatives Considered
>  >
>>  The technique described here is based on a decade of experience
>>  building large web applications in Perl and JSP.
>I would assume most of that decade was in Perl :)

Nope. About half and half.

>  > This was followed by
>>  six months experience with using JWAA in the conventional manner, by
>>  coding views and controllers into the same class, which is still my
>>  preferred way of working.
>Any time spent working with Velocity, or it's predecessor, WebMacro?

Yes, but not extensive. In a shop that was committed to an inhouse 
template language and not inclined to change.

>Also, you the application setup the search path - why does velocity have
>to regurgitate the search path for you on each failed request?  You can
always ask Velocity for the search path...

Why shouldn't exceptions report the problem exactly? It costs nothing 
to be explicit: e.g. "Couldn't find filename.xt in any of [ dir1, 
dir2, dir3 ]". As it now stands, its like a C compiler complaining 
"undefined variable" with no variable name or line number to go by.

>  > There ensued an in depth investigation of the Velocity source code
>>  and documentation to discover a fact that should have been obvious
>  > from the error message.
>Or, you could have looked back into your own code that was settingup the
>engine to discover what path you set up in the first place...

The filename was was obvious by inspection. What wasn't was the path 
being searched.

>Or you could have looked at the examples....

Which was the next step

>Or you could have asked a helpful and eager community for help...

True. I wasn't subscribed to this list until now. Confirmation 
requests got filtered to a folder I rarely browse. Point is, this 
wasn't an option then.

>  > It soon became apparent that Velocity was
>>  eaten through and through by what I'll call the "properties disease";
>>  the belief that "flexibility" is a goal worth striving for and that
>>  the best means of achieving that goal is to put anything that might
>>  ever need changing into properties files, resource files, XML files,
>>  as distinct from "hard-wiring" them into bad old Java code.
>Hm.  In terms of resources, which what seems to challenge you, we have
>found that it is a very flexible system...  that's why the creation of
>new loaders is so trivial and easy - they just plug in.  Velocity will
>read templates from files, but also from jars, the classpath, and even
>DataSources, if you are so inclined (and a user was and donated to the

This comment comes to the heart of the issue I keep trying to bring 
to jakarta's attention with respect to all projects, not just 
Velocity. Popping up a level...

There seems to be a core belief that users want and value 
flexibility, and that the way to provide it in Java is via 
dynamically bound techniques in lieu of solutions that are provided 
statically within Java. There are several articles on the my web site 
that challenge this belief; particularly the "The Problem" link at 
the top of the page.

The developers need to understand that when this user at least thinks 
about the flexibility of the jakarta projects I've experienced, 
flexible means "as when pushing a rope". To even get to the point of 
using Jakarta, users have to download, understand, and install 
apache, a connector (JServ, mod_jk, etc), and tomcat, each with its 
own configuration file peculariaties, each of which is tested only 
for syntactic validity, with any semantic invalidity exposed so that 
NullPointerExceptions turn up at runtime.

>  > No doubt
>>  this notion originated from C, which is certainly hard for most users
>>  to change.
>No, I think it originated from the idea that different users have
>different requirements, and different preferences.  For example,
>Velocity is used differently when developing vs production - in
>development, people generally dont' cache templates for immediate
>feedback.  I guess when you have to compile and deploy in JAWA, that
>kind of thing doesn't matter....

My problem is that properties/XML files aren't the only way of 
responding to differing requirements, and are often a very poor way, 
for applications like Velocity and Tomcat where every user knows Java 
already. Introducing other languages (and properties files and XML 
are both languages) makes the job harder, not easier. Overriding 
abstract classes can provide just as much configurability as 
properties or XML files, and this doesn't require support for special 
purpose configuration languages at runtime.

But however configuration values are specified, via properties files 
or Abstract classes, they must be tested for semantic validity before 
the application encounters them. If this were done reliably in all 
jakarta projects, many of my complaints about properties files would 
be moot.

>  > But this doesn't apply at all to Java, particularly since
>>  users can define abstract classes that override parameter settings as
>>  easily, and far more reliably, than changing values in properties
>>  files.
>Again, that means you have to rebuild when you change a setting.  In my
>experience, I would prefer if operations activities do *not* require
>operations staff to define abstract classes and recompile and
>redeploy...  To be frank, I think it's a dumb idea in the real world...
>might work in a hypothetical or academic construction, but in real life,
>that doesn't happen in my experience.

This is a real life application. All changes are made and tested on 
the development server. The deployment server is sacrosanct. No 
changes are
made there. If changing something on the deployment server were 
desired or required, there would be a valid application for 
properties files. But this would undercut the reason for having 
separate servers in the first place.

>Ok - lets assume the above has some valid examples behind it.  Would you
>like to elucidate so we can either debunk your misconceptions, or learn
>from what you are saying and fix it?
>>  By the end of three days of struggling with the completely trivial
>>  problem of where my template files should go, I found the answer.
>(Please let it be "I read the manual...")

Of course I read the manual. Its in there, buried way in the back. 
The need to deal with a properties file wasn't even mentioned in the 
quick start which is the relevant section for getting one's first 
template file to work. No instructions on where to put template files 
were there. It only came up way in the back.

>  > So I defined the variables
>>  that seemed appropriate, relaunched the application, and whammo; a
>>  NullPointerException from somewhere deep within Velocity, without
>>  even a variable name or line number to go by.
>Ok - this is something very, very serious.   This should never happen.
>If you would let us know the configuration that caused that, I would be
>very interested to fix immediately.  I am guessing what it was and will

Happy to help track it down. This is from memory since I've removed 
the Velocity files by now. As I recall, the real problem was that my 
template was at tomcat/webapps/appname/WEB-INF/template when (I since 
learned) it should have been at tomcat/webapps/appname/template.

So I tried moving it to various subdirectories. Nothing worked. So in 
the configuration option where you specify the file, class or jar 
loader, I reasoned that specifying the class loader would find the 
template file in the same directory with the class that requested it.

So I configured this line to read "file,class", which triggered the 
NullPointerException I mentioned. I didn't track it down any closer; 
the problem might be that I mispelled the class option, or the word 
"class" collided with Java somehow, or there was some other option I 
should have specified. Note the core problem: the lack of semantic 
validation of information from properties files.

>Ok.  Strawman is now set up... moving on to solution?


>  > A better solution would be to eliminate the reliance on MLS
>>  {{digraphs}} in template files and to provide a full parser for a
>>  template language similar to Velocity's. This parser would compile
>>  Velocity-style statements into Java statements at pre-compile time
>>  unlike Velocity's runtime approach. If you're interested in working
>  > on such a project, contact the author.

Condescending lecture deleted. I've uploaded everything I have to say 
to You won't be hearing from me again. 
In closing, I'll only add my disappointment in how closed this 
community is to constructive feedback, consideration of alternative 
technical approaches (static vs dynamic binding), and even offers to 
help (previous paragraph).
For industrial age goods there were checks and credit cards.
For everything else there is mybank.dom at
Brad Cox, PhD; 703 361 4751

View raw message