Re: WebWork and XWork

> It's not that I don't know what I'm doing.

I don't want to sound too rude here since I don't know the full story behind
why this code was added (and apologies in advance if I have the context of
this incorrect!), however I would beg to differ. I've been using Velocity
very extensively for almost 2 years now and have never needed to write a
method that looks like that. I even shot some water out my nose when I saw
it :)

Apart from breaking the Java naming convention (which Velocity NEVER
requires you to do), I cannot understand what the purpose of the "return
this;" is for - you have a reference to the "this" object anyway since you
managed to call the method in the first place right? Plus you return an
Object, yet surely you know what class "this" is?! The mind boogles.

Assuming you have the SelectTag object in the Velocity context under the
name "tag", you can call setEmptyOption() like so:

$tag.setEmptyOption(true);

To test if it is empty, you can use either:

#if ($tag.isEmptyOption()) ...

or just the shorthand notation #if ($tag.emptyOption) ...  (and
$tag.EmptyOption also works, although I never use that syntax personally).

Looking at the select.vm template it appears that this is indeed what
happens:

#if($tag.EmptyOption)<option></option>#end  hence that method does indeed
appear to be redundant.

This is all very fundamental Velocity stuff, and if you genuinely believe
that you know what you're doing then I'd have to agree that you shouldn't
have commit access. As a potential WW2 user I shudder to think the codebase
is polluted with code of this quality.

Note that after a quick glance at the codebase I'm very disturbed to see
that this is not an isolated incident. The taglib code appears to be stuffed
to the brim full of the very same hack repeated for each property...  Nice.

Chris





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf