Best way to handle optional attributes in 1.6.2

2009-06-13 Thread sebb
I'm generating HTML using a Velocity style sheet with version 1.6.2 The source contains lots of elements which are used to generate table cell entries: Description The "required" attribute is supposed to be "Yes" or "No", with a default of "No". The VSL currently has: #if($items.getAttributeV

Re: Best way to handle optional attributes in 1.6.2

2009-06-13 Thread Jude Robinson
> Is there a better way to handle optional attributes? "!$items.getAttributeValue('required')" != "" - To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org For additional commands, e-mail: user-h...@velocity.apache.org

Re: Best way to handle optional attributes in 1.6.2

2009-06-13 Thread Nathan Bubna
That should be: #if( "$!items.getAttributeValue('required')" != "" ) Or just $!items.getAttributeValue('required') if you don't mind showing empty strings. Or if you really want to clean up the look: public class AltTool { public Object empty(Object val, Object alt) { return (val == null

Re: Best way to handle optional attributes in 1.6.2

2009-06-15 Thread sebb
Thanks for the suggestions which work fine. There seems to have been a change in behaviour since version 1.5.1, but I could not find it in the release notes. Can anyone confirm this? On 14/06/2009, Nathan Bubna wrote: > That should be: > > #if( "$!items.getAttributeValue('required')" != "" ) >

Re: Best way to handle optional attributes in 1.6.2

2009-06-15 Thread Nathan Bubna
Your original VTL amounted to #if ( null != "" ) when there was no attribute value. The fact that this evaluated as false was a bug, since null doesn't equal the empty string. Several little, obscure comparison bugs like this were fixed prior to 1.6.2. I don't recall, though, under which commit

Re: Best way to handle optional attributes in 1.6.2

2009-06-15 Thread sebb
I see, thanks. On 15/06/2009, Nathan Bubna wrote: > Your original VTL amounted to #if ( null != "" ) when there was no > attribute value. The fact that this evaluated as false was a bug, > since null doesn't equal the empty string. Several little, obscure > comparison bugs like this were fi