> I'm kinda disappointed here, I came here with a valid issue and no one seems > to see a problem here,
No, You came with a valid issue and an alternative solution was provided. > I just want a syntax option improvement which will avoid some > behavior/performace issues. The problem is that we don't want a syntax improvement. > <t:if test="user.limit"> > it will return false even if limit is a zero, I see. So if "user.limit" is an Integer, and it's value is null or 0 then this will evaluate to false. That seems pretty straight forward for how you would expect an Integer to be evaluated. If you explicitly need to differentiate between null and 0 then you can add a method to your page/component. > I'm surprised that you didn't discover that kind of problem in big projects > with complicated view logic, The problem is a minor performance problem, not a functional one. Unit tests all continue to function. toString on most entities would take up a tiny fraction of the time required to actually build a large complex page. > I don't want to change default Object - > boolean coercion or somekind of > PropertyConduitSource hack, TypeCoercer is an integral part of Tapestry. You've found an issue in TypeCoercer that should be addressed in TypeCoercer. Object -> Boolean is a clean solution that follows an existing trusted design pattern. > it will break stuff and just admit nobody will change it in the framework so > don't argue that it could be fixed here. I'm not the only committer that believes the Object -> Boolean change is the correct approach. I've filed https://issues.apache.org/jira/browse/TAP5-1621 and intend to claim and fix it in the next week, unless another committer beats me too it. > even Howard suggested to use an approach which I would never suggest in our > team At the point Howard chimed in to the thread I don't think anyone understood what you were saying. It sounded like you were saying there was a functional problem, when in fact you were presenting a performance problem. > toString is getting called on unknown object to check if it isn't a "false" > is a little bit to much of Tapestry magic and I don't think that Tapestry > should force developers to use the only one way. Hehe... Tapestry is a complex framework filled with "magic". You may not know that the TypeCoercer is hard at work in the background, but there it is. The logical conversion from String -> Boolean is "true" and "false", the fact that Object -> String -> Boolean wasn't fixed sooner is purely because it works, and no one has seen a problem with it. > and I don't think that Tapestry should force developers to use the only one > way. <t:if test="myObject"/> <!-- currently forces Object -> String coercion, to be fixed -> <t:if test="!isNull(myObject)"/> <!-- provide a method in your component/page -> <t:if test="!myObjectIsNull"/> <!-- provide a property in your component/page -> <t:if test="notNull:myObject"/> <!-- create a binding -> <t:if test="ognl:myObject==null"/> <!-- third party binding --> I don't like the ? syntax you are suggesting. Josh On Fri, Aug 26, 2011 at 1:56 AM, Denis Stepanov <denis.stepa...@gmail.com> wrote: > Guys, > > I'm kinda disappointed here, I came here with a valid issue and no one seems > to see a problem here, I don't want to fix it in my project we are already > using ifNotNull component I just want a syntax option improvement which will > avoid some behavior/performace issues. > > It could pretty much confuse beginners because if someone will write: > > <t:if test="user.limit"> > > it will return false even if limit is a zero, it could be an expected > behaviour but if limit is valid/is set only if there is not null value you > are giving no quick option here. > > I don't want to change default Object - > boolean coercion or somekind of > PropertyConduitSource hack, it will break stuff and just admit nobody will > change it in the framework so don't argue that it could be fixed here. > > I'm surprised that you didn't discover that kind of problem in big projects > with complicated view logic, even Howard suggested to use an approach which I > would never suggest in our team, toString is getting called on unknown object > to check if it isn't a "false" is a little bit to much of Tapestry magic and > I don't think that Tapestry should force developers to use the only one way. > > Thanks, > Denis > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
