RE: [OS-webwork] OGNL madness - evaluated tag attributes

[Patrick Lightbody]

Hmm… this is pretty interesting. I’d like to hear the opinion from the 1.4 guys on this as well.   -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drew McAuliffe Sent: Friday, November 21, 2003 11:32 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] OGNL madness - evaluated tag attributes   One thing to keep in mind is that a velocity-style syntax to represent what will be evaluated is consistent with how stack evaluations are performed against data in the xwork config file. In that file, if you want the action result or result path to be dynamic, you do the ${dynamicValue} trick. It would be REALLY nice if the tags and velocity stuff worked the same way, so that the same syntax is used throughout the framework. Perhaps the manner in which evaluation is performed could be switched via a webwork.properties setting, so that with one setting, you do it with the triple-quote (for backwards compatibility) and another way, you do it with velocity-style ${} syntax.   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Lightbody Sent: Friday, November 21, 2003 5:16 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] OGNL madness - evaluated tag attributes Well, this is to be compatible with 1.x… so I think the 1.x guys should get involved in the discussion at this point…   -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Douglass Sent: Friday, November 21, 2003 1:32 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] OGNL madness - evaluated tag attributes   I couldn't agree more. I've always found the triple-quoting ugly... makes my brain go all scrambled eggs. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Drew McAuliffe Sent: Friday, November 21, 2003 8:05 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] OGNL madness - evaluated tag attributes 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....   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Patterson Sent: Friday, November 21, 2003 6:38 AM To: Webwork Subject: [OS-webwork] OGNL madness - evaluated tag attributes 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