velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Stevens <>
Subject Re: Can I write a macro that can call itself?
Date Fri, 13 Jul 2001 22:21:05 GMT
on 7/13/01 2:57 PM, "Brad Cox" <> wrote:

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

The thing is that there should only be a few well defined objects that are
placed into the Context. So, the type checking isn't really necessary
because it is easy to debug as well as write a test for.



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

So, you question the use and implementation of Velocity even though you
haven't used it yourself? Hmmmmm...

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

I'm pretty sure that the log file reports which directories where loaded by
the file resource loader. If the file isn't found in that directory then it
is pretty clear where the problem is.

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


Fri Jul 13 12:16:03 PDT 2001   [info] FileResourceLoader : initialization
Fri Jul 13 12:16:03 PDT 2001   [info] FileResourceLoader : adding path

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

That belief is based on reality though.

> 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

"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 problem is that it is very difficult to guess every single different
configuration and use of our software as well as catch that usage perfectly.
We try our best, but sometimes it isn't always easy.

Needless to say, I'm not really sure what the point of what you are trying
to say is. Are you saying that we should make things easier for our users?
Are you saying that we intentionally make things difficult? If so, then let
me point you at this document:


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


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

Because there are examples that show you how to do things.

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

All the information you needed was in the log file. See above.

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

Your response was not constructive feedback. It was a silly rant.



View raw message