Re: type coersion - numbers and booleans

[Paul Stanton]

While I agree with both of you - accessor methods in java classes is 
generally better than (minor) logic in templates, there are cases where 
some logic in templates is preferable, ie when there are perhaps 10's or 
more different numeric cases on the same property. having 10+ near 
identical methods doing a simple numeric equals is less maintainable.


in these cases, i miss ognl!

instead of a new component, i've written a public method:

isPropertyEquals(int value)
{
return myproperty == value;
}

p.

On 4/08/2012 1:03 PM, Thiago H de Paula Figueiredo wrote:
On Fri, 03 Aug 2012 21:07:27 -0300, Howard Lewis Ship 
hls...@gmail.com wrote:



public boolean isNumberThree() { return numericValue == 3; }


In other words, don't put logic in templates, put them in Java 
classes, where it can be easily debugged and tested. ;)





-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: type coersion - numbers and booleans

[Howard Lewis Ship]

public boolean isNumberThree() { return numericValue == 3; }

Yes, there's some leaky abstractions with method invocations and all
the parameter coercion going on. However, given live class reloading,
creating ad-hoc properties for these comparisons is often more
comparable.  Also, instead of isNumberThree() it could have semantic
value, as in isShowExtendedDetails().

Finally, you can write your own IfEquals component that compares its
two parameters using whatever mechanism works for you.

On Fri, Aug 3, 2012 at 3:34 PM, Paul Stanton p...@mapshed.com.au wrote:
 hi all,

 originally have an accessor method:

 public int getNumericValue()
 {
return myInteger; // auto-boxes to int
 }

 and wanted to use the following if:

 t:if test=numericValue == 3

 however '==' doesn't work, but i know method calls work so i changed to:

 public Integer getNumericValue()
 {
 return myInteger; // no boxing
 }

 and
 t:if test=numericValue.equals(3)

 this still didn't work, reason being, tapestry 'coerces' 3 into new
 Long(3) and

 new Integer(3) .equals(new Long(3))

 returns false.

 So i've changed to

 public Long getNumericValue()
 {
 return new Long(myInteger); // a bit ugly
 }

 and
 t:if test=numericValue.equals(3)

 now works

 SO

 should tapestry do a better job of
 a) coercing 'primative == primative' and the like
 b) coercing '3' to 'new Integer(3)' when it is preferable
 c) nothing, everything above is as it should be.


 discuss...

 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org




-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: type coersion - numbers and booleans

[Thiago H de Paula Figueiredo]

On Fri, 03 Aug 2012 21:07:27 -0300, Howard Lewis Ship hls...@gmail.com  
wrote:



public boolean isNumberThree() { return numericValue == 3; }


In other words, don't put logic in templates, put them in Java classes,  
where it can be easily debugged and tested. ;)


--
Thiago H. de Paula Figueiredo

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org