I kind of agree. I think triple-quoting simple parameters
like "name" is kind of silly. In fact, I've never really liked the
triple-quoting much at all (it seems unwieldy to me), though I understand the
need for it. To me, it might be easier to just ditch the whole triple-quote
thing and do the evaluation velocity style, with a ${} combination indicating
something that should be evaluated (e.g., name="someName"
value="${evaluateThis}"). Though of course I'd expect that to be
controversial....
Hi,
I have just run my app with the release candidate
and am in the process of changing many (but not all) of the tag attributes to
use single quotes for literals. I am thinking that in many instances,
evaluating the attribute tag is not really very helpful. For example,
the Bean tag has an attribute 'name' for the name of the class to
instantiate. This is now treated as an OGNL _expression_ and evaluated to
derive the name of the class to use. OGNL madness!
In 99% of cases it seems that this attribute does
not need to be evaluated. Forcing the developer to "triple quote" values
most of the time will lead to annoying, hard to spot, errors (and already has
for me). What may have been a step forward for compatibility has IMHO
been a large step backwards in usability.
So what I am suggesting is that we only evaluate
attributes where that would be the expected common usage. We would need to use a standard way of naming
literal expressions that are NOT treated as OGNL expressions. For
example, attributes called 'name' could be treated as literals but passed
through the TextUtil thing (so you can use
name="${first}-${second}").
Attributes called "value" on the other hand are
often variant and therefore would make sense to evaluate them. You would
then have to "triple quote" them to use a literal. For those who think
that this would break consistency, consider that not all attributes are
currently evaluated (eg Iterator status, Set name). So in fact,
introducing such a naming standard would increase consistency (maybe at the
expense of backward compatibility)
John
