long properties?

[Rickard Öberg <ri...@xpedio.com>]

Hey

I have a property which is of type long. I try to set it using this
syntax:
$foo.setValue(123)

But it doesn't work. If I change the property to type int, it works. Is
this a limitation of Velocity, or am I doing something wrong?

/Rickard

-- 
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: rickard@xpedio.com

Re: long properties?

["Geir Magnusson Jr." <ge...@optonline.net>]

Attila Szegedi wrote:
> 
> Delegating as much of work as possible to java.beans.Introspector instead of
> using reflection directly would definitely be a good idea for the very
> reason Rickard brought up: if Velocity discovered properties and methods
> through java.beans.Introspector, it would honor custom property and method
> descriptors created by the developer of the bean.
> 
> As an additional benefit, you could always be sure that the automatic
> discovery of properties through reflection (which Introspector does if there
> is no explicit BeanInfo) is 100% JavaBeans compliant :-).For the record,
> Velocity's manual reflection lookup is not as it does not recognize "boolean
> isXxx()" as a property read method, and maybe there are other issues as
> well.

Interesting idea.  You are right about isXXX()...

geir

> 
> As a future advanced functionality, PropertyEditor#getAsText() could be used
> to render objects returned from a property call on a bean instead of using
> toString() on the object. But this really is a future RFE.
> 
> Attila.
> 
> ----- Original Message -----
> From: "Rickard Öberg" <ri...@xpedio.com>
> To: <ve...@jakarta.apache.org>
> Sent: 2001. augusztus 6. 23:55
> Subject: Re: long properties?
> 
> <snip/>
> 
> >
> > Weeeell... in most (all?) cases the overloading of these kinds of
> > methods (=polymorphism on Number class) is simply to allow several input
> > types to do the same thing. I.e. simply choosing the first method you
> > can find should be ok.
> >
> > However, the proper way (which we use in WebWork so look there for
> > example code) is to use the JavaBeans API along with PropertyEditors.
> > I.e. a JavaBean may have a BeanInfo listing the properties, and there
> > specify how to set the value by using a PropertyEditor. This way the
> > creator of the code has full control over how to handle it.
> >
> > /Rickard
> >
> > --
> > Rickard Öberg
> > Software Development Specialist
> > xlurc - Xpedio Linköping Ubiquitous Research Center
> > Author of "Mastering RMI"
> > Email: rickard@xpedio.com
> >

-- 
Geir Magnusson Jr.                           geirm@optonline.net
System and Software Consulting
Developing for the web?  See http://jakarta.apache.org/velocity/
Well done is better than well said - New England Proverb

Re: long properties?

[Attila Szegedi <sz...@freemail.hu>]

Delegating as much of work as possible to java.beans.Introspector instead of
using reflection directly would definitely be a good idea for the very
reason Rickard brought up: if Velocity discovered properties and methods
through java.beans.Introspector, it would honor custom property and method
descriptors created by the developer of the bean.

As an additional benefit, you could always be sure that the automatic
discovery of properties through reflection (which Introspector does if there
is no explicit BeanInfo) is 100% JavaBeans compliant :-).For the record,
Velocity's manual reflection lookup is not as it does not recognize "boolean
isXxx()" as a property read method, and maybe there are other issues as
well.

As a future advanced functionality, PropertyEditor#getAsText() could be used
to render objects returned from a property call on a bean instead of using
toString() on the object. But this really is a future RFE.

Attila.

----- Original Message -----
From: "Rickard Öberg" <ri...@xpedio.com>
To: <ve...@jakarta.apache.org>
Sent: 2001. augusztus 6. 23:55
Subject: Re: long properties?


<snip/>

>
> Weeeell... in most (all?) cases the overloading of these kinds of
> methods (=polymorphism on Number class) is simply to allow several input
> types to do the same thing. I.e. simply choosing the first method you
> can find should be ok.
>
> However, the proper way (which we use in WebWork so look there for
> example code) is to use the JavaBeans API along with PropertyEditors.
> I.e. a JavaBean may have a BeanInfo listing the properties, and there
> specify how to set the value by using a PropertyEditor. This way the
> creator of the code has full control over how to handle it.
>
> /Rickard
>
> --
> Rickard Öberg
> Software Development Specialist
> xlurc - Xpedio Linköping Ubiquitous Research Center
> Author of "Mastering RMI"
> Email: rickard@xpedio.com
>

Re: long properties?

[Rickard Öberg <ri...@xpedio.com>]

"Geir Magnusson Jr." wrote:
> 
> Rickard Öberg wrote:
> >
> > "Geir Magnusson Jr." wrote:
> > > I will look into this.
> > >
> > > One issue that we have run into before related to this is that things
> > > like Double extend Number, so then things become problematic
> > >
> > > $foo.setVal( $woogie )
> > >
> > >  if $woogie is a Double  and  public void setVal( int ), then you might
> > > not get what you want, esp if there is a public void setVal( float ) or
> > > setVal( Double ) or...
> >
> > Good point. There should be a "good enough" solution to this though.
> 
> Definately - we should handle the broadening...  I am just wary of the
> Number approach.

Weeeell... in most (all?) cases the overloading of these kinds of
methods (=polymorphism on Number class) is simply to allow several input
types to do the same thing. I.e. simply choosing the first method you
can find should be ok.

However, the proper way (which we use in WebWork so look there for
example code) is to use the JavaBeans API along with PropertyEditors.
I.e. a JavaBean may have a BeanInfo listing the properties, and there
specify how to set the value by using a PropertyEditor. This way the
creator of the code has full control over how to handle it.

/Rickard

-- 
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: rickard@xpedio.com

Re: long properties?

["Geir Magnusson Jr." <ge...@optonline.net>]

Rickard Öberg wrote:
> 
> "Geir Magnusson Jr." wrote:
> > I will look into this.
> >
> > One issue that we have run into before related to this is that things
> > like Double extend Number, so then things become problematic
> >
> > $foo.setVal( $woogie )
> >
> >  if $woogie is a Double  and  public void setVal( int ), then you might
> > not get what you want, esp if there is a public void setVal( float ) or
> > setVal( Double ) or...
> 
> Good point. There should be a "good enough" solution to this though.

Definately - we should handle the broadening...  I am just wary of the
Number approach.

> > > Either that or introduce some casting possibilities. The magical convert
> > > is better though I think.
> >
> > No casting :)
> 
> :-) Point taken. I guess a template language should be as easy to use as
> possible.
> 
> Well, what I did now was to introduce a bunch of
> "toString"/"toInt"/"toLong" methods in my utility class, which is ok,
> but the code looks a little messy:
> $week.setFirst($webwork.toLong(1))
> 
> Not very nice, but works.

No, not pretty indeed.

However, it's really useful as a general helper, something that we
should add to the library of helper / tool classes in Rupert. (in
Jakarta Commons sandbox)

geir

-- 
Geir Magnusson Jr.                           geirm@optonline.net
System and Software Consulting
Developing for the web?  See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.

Re: long properties?

[Rickard Öberg <ri...@xpedio.com>]

"Geir Magnusson Jr." wrote:
> I will look into this.
> 
> One issue that we have run into before related to this is that things
> like Double extend Number, so then things become problematic
> 
> $foo.setVal( $woogie )
> 
>  if $woogie is a Double  and  public void setVal( int ), then you might
> not get what you want, esp if there is a public void setVal( float ) or
> setVal( Double ) or...

Good point. There should be a "good enough" solution to this though.

> > Either that or introduce some casting possibilities. The magical convert
> > is better though I think.
> 
> No casting :)

:-) Point taken. I guess a template language should be as easy to use as
possible.

Well, what I did now was to introduce a bunch of
"toString"/"toInt"/"toLong" methods in my utility class, which is ok,
but the code looks a little messy:
$week.setFirst($webwork.toLong(1))

Not very nice, but works.

/Rickard

-- 
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: rickard@xpedio.com

Re: long properties?

["Geir Magnusson Jr." <ge...@optonline.net>]

Rickard Öberg wrote:
> 
> Rickard Öberg wrote:
> > I have a property which is of type long. I try to set it using this
> > syntax:
> > $foo.setValue(123)
> >
> > But it doesn't work. If I change the property to type int, it works. Is
> > this a limitation of Velocity, or am I doing something wrong?
> 
> I think I found it. In ASTReference.setValue() the code only checks for
> integer set-methods (since ASTNumberLiteral will always produce an
> Integer). The setValue code should be modified to handle this case.
> Preferably it should check for all Number-type methods and convert the
> ASTNumberLiteral to whatever Number-type is to be used.

I will look into this.

One issue that we have run into before related to this is that things
like Double extend Number, so then things become problematic 

$foo.setVal( $woogie )

 if $woogie is a Double  and  public void setVal( int ), then you might
not get what you want, esp if there is a public void setVal( float ) or
setVal( Double ) or...

> 
> Either that or introduce some casting possibilities. The magical convert
> is better though I think.

No casting :)

geir
 
> /Rickard
> 
> --
> Rickard Öberg
> Software Development Specialist
> xlurc - Xpedio Linköping Ubiquitous Research Center
> Author of "Mastering RMI"
> Email: rickard@xpedio.com

-- 
Geir Magnusson Jr.                           geirm@optonline.net
System and Software Consulting
Developing for the web?  See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.

Re: long properties?

[Rickard Öberg <ri...@xpedio.com>]

Rickard Öberg wrote:
> I have a property which is of type long. I try to set it using this
> syntax:
> $foo.setValue(123)
> 
> But it doesn't work. If I change the property to type int, it works. Is
> this a limitation of Velocity, or am I doing something wrong?

I think I found it. In ASTReference.setValue() the code only checks for
integer set-methods (since ASTNumberLiteral will always produce an
Integer). The setValue code should be modified to handle this case.
Preferably it should check for all Number-type methods and convert the
ASTNumberLiteral to whatever Number-type is to be used.

Either that or introduce some casting possibilities. The magical convert
is better though I think.

/Rickard

-- 
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: rickard@xpedio.com