velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: Can I write a macro that can call itself?
Date Sat, 14 Jul 2001 01:44:43 GMT

Brad Cox wrote:
> 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....

anything you want.  "Rupert" if it makes you happy :)  I just tend to
refer to them as 'template authors' and let the HR department worry
about titles :)

> >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. 

Well, sort of.  It's more akin to late binding, because you resolve the
reference at runtime.  If you can't stand that, the I can't see how you
can stand Java...

> 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.

Except that it's a late binding-like issue, because Velocity doesn't
force you to strongly type your data objects.  It's something I refer to
as 'introspective polymorphism' - if it looks like a duck....  it allows
a very useful flexibility.
> >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.

My point is that it doesn't seem to be a 1-1 correspondence between
input and output?
> >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.

However, many do.  I have two clients that *do* require it, and the
dynamic approach of skinning through a custom frame that supplies a
branded layout, navigation and color scheme is very powerful - the
content never needs to be modified....  
> >  > 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.

Ok.  Fair enough.  (Although I am still trying to figure out the
> >  > 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.

I didn't think JSP was around that long ago - nor would I imagine that
if it was, you would want to build a large web app out of it...  my
mistake, I guess.
> >  > 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.

The problem is that you can have multiple loaders running, and not
everything is a file, nor does it live in a directory.  In fact, the
classpath resource loader *can't* tell you where it looked, becuase it
depends on the webapps classloader...

The loaders, at startup, independantly declare their configuration to
the log.  So I see no reason why you would need to repeat the same
information over and over again. I suspect that there is nothing you can
do at runtime anyway - you aren't going to parse the exception
> >  > 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.

I am sure the log mentions it.  If not, that's good feedback, and will
be taken care of immediately.
> >Or you could have looked at the examples....
> Which was the next step

Ok.  That tends to be my first step for me to get rid of preconcieved
notions... :)
> >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
> >project...)
> 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.

The only truth I see in this is that we can do a better job of making
sure that a 'common configuration' of defaults is setup internally (like
Velocity does - you don't need *any* external properties for the engine
to run - the only thing you need to know is that the file resource
loader is the default, and the default path is the 'current
directory'...), and that log output reflects the state better and offers
hints about choices.  Velocity does this. (See what the VM output is
like... it's pretty damn clear, I think...)

On the other hand, we are talking about software that can be used for
relatively sophisticated applications - I believe that external
configuration is better than compile/make/build time configuration for
reasons that have been explained through satire on this list earlier
> >  > 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.

Velocity has no requirements for using j.u.Properties, XML, etc as the
configuration mechanism.  The supported configuration API for the engine
consists of set/get methods, and a clear method.  Convenience functions
are offered that accept a Properties or a jakarta-commons
'ExtendedProperties' class - however, they are really there to make life
easier for the average application programmer, who indeed will commonly
use a j.u.Properties for configuration of their app in general.

Otherwise, you can use any mechanism you choose for storage /
maintenance of configuration values, and just use the get/set/clear
interface to setup the engine before init().
> 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.

it's open source - feel free to pitch in.  We have and will continue to
work very hard in Velocity to make it as easy as possible - that's why
we have a built in set of default configuration values.  So you can just
use it in the simplest of cases.

> >  > 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.

However, in real life you then have to completely regression test the
new server everytime you modify an aspect of configuration, because you
rebuild the entire server.  Anything else seems to be like flying by the
seat of the pants, so to speak.

Can you imagine if servlet containers were built this way?  Would you
want to rebuild your servlet or applcation server anytime a new EJB or
web app was deployed?  No thanks.

Does this philosophy extend to operating systems, login shells?  I mean,
do you want to recompile bash everytime you modify the path?

> >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.

Ok.  I'll fix that - the README in the servlet_examples are pretty clear
on how they work.  If the README's aren't correct in some way, let me
> >  > 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
> >investigate..
> 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.

It can be anywhere you want.  In a database even.  So I don't believe
that you got an NPE from within Velocity by having a template in a wrong
place.  I'd bet serious money on it...  I certainly have bet serious
amounts of my time making sure of it...

> 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.

Ah, the Monte Carlo approach.  :)  No, that's not correct.  From the
developers guide, section 10, titled (strangely enough) "Configuring
Resource Loaders"...

"ClasspathResourceLoader : This loader gets resources from the
classloader. While the classpath is a source of great pain and suffering
in general, it is a very useful mechanism when working on a Servlet Spec
2.2 compliant servler runner. Tomcat is an example of such. To use this
loader effectively, all you must do is jar your templates, and put that
jar into the WEB-INF/lib directory of your webapp. There are no
configuration options to worry about, nor is the absolute vs. relative
path an issue, as it is with Jar and File resource loaders. "

I may be biased because I wrote it, but it seems pretty clear...
> 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.

Yep - that's what I thought you did :)  I know that one.  Will be fixed.

I think the core problem is that you didn't read the docs.  Again,
section 10, "Configuring Resource Loaders" :

"Multiple Loader Configuration : This configuration sets up three
loaders at the same time, the FileResourceLoader, the
ClasspathResourceLoader, and the JarResourceLoader. The loaders are
set-up such that the FileResourceLoader is consulted first, then the
ClasspathResourceLoader, and finally the JarResourceLoader. This would
allow you to qickly drop a template into the file template area to
replace on of the templates found in the classpath (usually via a jar)
without having to rebuild the jar....."

(example does follow...)

Again, as I wrote that, I am biased, but I think it's clear :)

> >Ok.  Strawman is now set up... moving on to solution?
> See
> >  > 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. 

"Condescending lecture"?  Various responses leap to mind - however, I
will simply note that the so called 'condescending lecture' simply
observed that you are promoting your own project on our user list (which
is fine by me, btw) without the courtesy of explaining to the community
the advantages that JAWA offers, other than some vague references to
compile time type checking.  The only exception to this was you noting
that you had trouble setting up Velocity, and made it clear that you
didn't want to either consult the user community here, or even read the
If you give Velocity a good look, I am sure you can come up with more
problems with Velocity.  I have a list a mile long - however, I am
working to fix them...

> 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).

Closed?  If you read more of the 'condescending lecture', I state
clearly that I ( and I am sure others) are interested in discussing pros
and cons of view technologies.   I am just not sure that I (speaking for
myself now) am interested in hearing about configuration troubles as a
proxy for real understanding of what Velocity's strengths and
limitations are.

If you want a real discussion, lets have a real discussion. If you look
at the archives of this list, you will see that we are very open to
discussing other alternatives (and I am always engaging the WebMacro
community on design and philosophy) as well as other frameworks.

We are always ready to jump to the rescue when someone has configuration
problems - we do it to help people get started, and also to understand
what we can do to make Velocity better....


> --
> For industrial age goods there were checks and credit cards.
> For everything else there is mybank.dom at
> Brad Cox, PhD; 703 361 4751

Geir Magnusson Jr.                 
System and Software Consulting
Developing for the web?  See
You have a genius for suggesting things I've come a cropper with!

View raw message