good call dale!
http://freemarker.org/docs/ref_builtins_expert.html
implementing has_content will definitely detect no content condition
without consulting gray's anatomy for 'systemic' I cant say if this is
related to 'aortic' maladies rather than pulmonary?
but thats a topic for another day..
Thanks
Martin--
----- Original Message -----
From: "Dale Newfield" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <user@struts.apache.org>
Sent: Saturday, December 15, 2007 11:12 PM
Subject: Re: [struts][2.0.11] optiontransferselect limit?
> Dale Newfield wrote:
> > Martin Gainty wrote:
> >> this is the applicable code in my copy of optiontransferselect.ftl
>
> Thanks for making me look at this--it led me straight to my problem!
>
> > So we know there is a problem with the freemarker libraries, and that
> > it's either in ?exists, or stack.findString(), or in the assumption that
> > the first being true implies the second will always produce a valid
> > result. Is it true that if it has a value that value must be
> > extractable as a string? The freemarker docs suggest that maybe
> > ?has_content would be better than ?exists ...
>
> This rational is almost right, but has a big hole. We're asking whether
> the tag has a parameter set, and then assuming the data has not null for
> that attribute. I indeed had a piece of data with null for that value,
> which caused my problem. Since that attribute was derived, I was able
> to modify my model object to return "" in that case instead of null, and
> I'm golden. I might suggest this alteration to the .ftl file, though:
>
> <#if parameters.doubleListValue?exists><#t/>
> + <#if
> stack.findString(parameters.doubleListValue)?has_content><#t/>
> <#assign doubleItemValue =
> stack.findString(parameters.doubleListValue) /><#t/>
> + </#if><#t/>
> <#else><#t/>
> <#assign doubleItemValue = stack.findString('top') /><#t/>
> </#if><#t/>
>
> Now I don't have to change interfaces for large groups! Yay! Thanks!
>
> -Dale
>
> P.S.: I shoulda known that 1124 was not a magic enough number to be a
> systemic problem--that number should have led me to look at my data
> sooner :-/.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
