You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Geir Magnusson Jr." <ge...@optonline.net> on 2001/02/01 19:29:09 UTC
introspection 'enhancement'
I added a small fix to the 'case sensitivity' of properties, as this was
recently discussed sort of :
If you have a method
getFoo()
and in your template you do
$bar.foo
we will try getfoo() first, and then getFoo() if getfoo() isn't found.
And in the interest of symmetry, we do the reverse. If you are wierd,
and have a method
getfoo()
and your designer has a clue :
$bar.Foo
then we try getFoo() first, and then getfoo() second.
I am queasy a little about this, but even queasier about not having it,
and someone is going to ask for it anyway :)
Note that the best strategy for performance is to get it right, to limit
the amount of expensive introspection...
Note also that I believe this is an inversion of the bean spec, rather
than a literal reading. As I read it, the bean spec talks about this
when dealing with naming a property that it finds a pair of matched
getter/setter methods. We are going the other way, finding the
getter/setter methods given a property name.
(I will make set work the same way....)
geir
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
Re: AW: introspection 'enhancement'
Posted by Jon Stevens <jo...@latchkey.com>.
on 2/2/01 7:37 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> Then, after reading your post, I figured/suggested/agreed that we should
> always do getBar() first
+1
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/> | <http://java.apache.org/turbine/>
Re: AW: introspection 'enhancement'
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Christoph Reck wrote:
>
> OK, I didn't vote against your enhancement, I just was echoing
> the "keep it(Velocity) simple" recommendation!
>
> I don't care if it's $foo.Bar or $foo.bar (which looks nicer
> and is more what Java pople are acustomed).
What the code does is :
$foo.Bar -> getBar() and then getbar() if getBar() failed
$foo.bar -> getbar() and then getBar() if getbar() failed
Then, after reading your post, I figured/suggested/agreed that we should
always do getBar() first, because that is most likely what will be in
the code, then getbar() for the nonconformists...
>
> > Right. But we don't require that objects in the context are beans...
> > It's helpful, but not required.
>
> If you try getBar() before getbar(), I don't mind the (size)overhead,
> it's fine with me...
>
> Thanks for your good moderating and sweat/frustration with Vel.
>
> :) Christoph
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
Re: AW: introspection 'enhancement'
Posted by Christoph Reck <Ch...@dlr.de>.
OK, I didn't vote against your enhancement, I just was echoing
the "keep it(Velocity) simple" recommendation!
I don't care if it's $foo.Bar or $foo.bar (which looks nicer
and is more what Java pople are acustomed).
> Right. But we don't require that objects in the context are beans...
> It's helpful, but not required.
If you try getBar() before getbar(), I don't mind the (size)overhead,
it's fine with me...
Thanks for your good moderating and sweat/frustration with Vel.
:) Christoph
Re: AW: introspection 'enhancement'
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
"Geir Magnusson Jr." wrote:
>
> (And lets stop posting to both -user and -dev... )
Please ignore the above :)
Mentally foggy morning...
geir
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
Re: AW: introspection 'enhancement'
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
<nibble, nibble.... tug>
(And lets stop posting to both -user and -dev... )
Christoph Reck wrote:
>
> > I don't think the bean spec actually states this, but if you can tell me
> > where, I would be happy to know.
> >
> > We *infer* this, but as far as I can tell, it doesn't say it.
>
> Section 8.3 of beans_101.pdf (http://java.sun.com/beans/docs/spec.html)
> states:
> "If we discover a matching pair of get<PropertyName> and
> set<PropertyName> methods that take and return the same
> type, then we regard these methods as defining a read-write
> property whose name will be <propertyName>. We will use the
> get<PropertyName> method get the property value and the
> set<PropertyName> method to set the property value. The pair
> of methods may be located either in the same class or one may
> be in a base class and the other may be in a derived class.
>
> If we find only one of these methods, then we regard it as
> defining either a read-only or a write-only property called
> <propertyName>"
>
> It clearly differentiates between set<PropertyName> and <propertyName>
> where the case of the first letter is different. This is standard
> Java coding convention. The JavaBean specification just uses the
> convention without needing to say this explicetely.
Right! We *infer* it from the Java coding convention. Like I said -
this points to the direction of finding a set of methods set<Propname>
and get<Propname> to infer a property <propname> (see section 8.8
also).
We go the other direction, having a <propname> and then search for a
matching getter / setter.
I do agree that we should support this pattern. I was only arguing that
that the spec doesn't actually spell out what we infer.
> If somebody
> does not follow the Java and bean conventions, it is not a JavaBean
> and tools will not to work according with the bean spec on it.
Right. But we don't require that objects in the context are beans...
It's helpful, but not required.
> In a separate mail on this I said the users of non-bean setter
> methods can call the method explicetly.
I disagree, and responded to that post, so won't repeat it here.
> :) Christoph
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
Re: AW: introspection 'enhancement'
Posted by Christoph Reck <Ch...@dlr.de>.
> I don't think the bean spec actually states this, but if you can tell me
> where, I would be happy to know.
>
> We *infer* this, but as far as I can tell, it doesn't say it.
Section 8.3 of beans_101.pdf (http://java.sun.com/beans/docs/spec.html)
states:
"If we discover a matching pair of get<PropertyName> and
set<PropertyName> methods that take and return the same
type, then we regard these methods as defining a read-write
property whose name will be <propertyName>. We will use the
get<PropertyName> method get the property value and the
set<PropertyName> method to set the property value. The pair
of methods may be located either in the same class or one may
be in a base class and the other may be in a derived class.
If we find only one of these methods, then we regard it as
defining either a read-only or a write-only property called
<propertyName>"
It clearly differentiates between set<PropertyName> and <propertyName>
where the case of the first letter is different. This is standard
Java coding convention. The JavaBean specification just uses the
convention without needing to say this explicetely. If somebody
does not follow the Java and bean conventions, it is not a JavaBean
and tools will not to work according with the bean spec on it.
In a separate mail on this I said the users of non-bean setter
methods can call the method explicetly.
:) Christoph
Re: AW: AW: introspection 'enhancement'
Posted by Christoph Reck <Ch...@dlr.de>.
Thomas Fahrmeyer wrote:
>
> I looked in the Bean 1.01 spec for the naming conventions of accessor
> methods.
>
> You are right Geir. It is not defined to write "getMethod" but it's
> explicitly described in the accessor design pattern chapter of the spec.
>
The capitalization *is* explicetely stated (as the inverse when
going from a method- or listener name to the property name). See
section "8.8 Capitalization of inferred names" of the Bean 1.01
spec. It also states: "the name will, by default, begin with a
capital letter."
Inverting this rule makes the uppercasing the first letter to
define the setter method conform with the spec.
:) Christoph
AW: AW: introspection 'enhancement'
Posted by Thomas Fahrmeyer <th...@einsurance.de>.
I looked in the Bean 1.01 spec for the naming conventions of accessor
methods.
You are right Geir. It is not defined to write "getMethod" but it's
explicitly described
in the accessor design pattern chapter of the spec.
> -----Ursprungliche Nachricht-----
> Von: gmj@optonline.net [mailto:gmj@optonline.net]Im Auftrag von Geir
> Magnusson Jr.
> Gesendet: Freitag, 2. Februar 2001 12:33
> An: velocity-user@jakarta.apache.org
> Betreff: Re: AW: introspection 'enhancement'
>
>
> Thomas Fahrmeyer wrote:
> >
> > Hi,
> >
> > I asked for that ;)
>
> Ya got it...
>
> >
> > It's a very flexible approach, but is it not too complicate ?
> The Bean spec
> > says that after a "get" or "set" (in a method name) must follow
> a uppercase
> > letter. So expect that a method in this signature is defined.
> And now just
> > convert the first letter of every property to uppercase and lool up the
> > method.
>
> I don't think the bean spec actually states this, but if you can tell me
> where, I would be happy to know.
>
> We *infer* this, but as far as I can tell, it doesn't say it.
>
> >
> > I think that makes the designer life easier and the programmer
> knows what he
> > have to do anyway (mostly) ;)
>
> agreed
>
> > It's just very nice to write $user.name instead of $user.Name
> >
> > Thomas
>
>
> --
> Geir Magnusson Jr. geirm@optonline.com
> Velocity : it's not just a good idea. It should be the law.
> http://jakarta.apache.org/velocity
Re: AW: introspection 'enhancement'
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Thomas Fahrmeyer wrote:
>
> Hi,
>
> I asked for that ;)
Ya got it...
>
> It's a very flexible approach, but is it not too complicate ? The Bean spec
> says that after a "get" or "set" (in a method name) must follow a uppercase
> letter. So expect that a method in this signature is defined. And now just
> convert the first letter of every property to uppercase and lool up the
> method.
I don't think the bean spec actually states this, but if you can tell me
where, I would be happy to know.
We *infer* this, but as far as I can tell, it doesn't say it.
>
> I think that makes the designer life easier and the programmer knows what he
> have to do anyway (mostly) ;)
agreed
> It's just very nice to write $user.name instead of $user.Name
>
> Thomas
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
AW: introspection 'enhancement'
Posted by Thomas Fahrmeyer <th...@einsurance.de>.
Hi,
I asked for that ;)
It's a very flexible approach, but is it not too complicate ? The Bean spec
says that after a "get" or "set" (in a method name) must follow a uppercase
letter. So expect that a method in this signature is defined. And now just
convert the first letter of every property to uppercase and lool up the
method.
I think that makes the designer life easier and the programmer knows what he
have to do anyway (mostly) ;)
It's just very nice to write $user.name instead of $user.Name
Thomas
> -----Ursprungliche Nachricht-----
> Von: gmj@optonline.net [mailto:gmj@optonline.net]Im Auftrag von Geir
> Magnusson Jr.
> Gesendet: Donnerstag, 1. Februar 2001 19:29
> An: velocity-dev; velocity-user
> Betreff: introspection 'enhancement'
>
>
> I added a small fix to the 'case sensitivity' of properties, as this was
> recently discussed sort of :
>
> If you have a method
>
> getFoo()
>
> and in your template you do
>
> $bar.foo
>
> we will try getfoo() first, and then getFoo() if getfoo() isn't found.
>
> And in the interest of symmetry, we do the reverse. If you are wierd,
> and have a method
>
> getfoo()
>
> and your designer has a clue :
>
> $bar.Foo
>
> then we try getFoo() first, and then getfoo() second.
>
> I am queasy a little about this, but even queasier about not having it,
> and someone is going to ask for it anyway :)
>
> Note that the best strategy for performance is to get it right, to limit
> the amount of expensive introspection...
>
> Note also that I believe this is an inversion of the bean spec, rather
> than a literal reading. As I read it, the bean spec talks about this
> when dealing with naming a property that it finds a pair of matched
> getter/setter methods. We are going the other way, finding the
> getter/setter methods given a property name.
>
> (I will make set work the same way....)
>
> geir
>
>
> --
> Geir Magnusson Jr. geirm@optonline.com
> Velocity : it's not just a good idea. It should be the law.
> http://jakarta.apache.org/velocity