For the record, issue created with patch. https://issues.apache.org/jira/browse/TAP5-1064
On Fri, Mar 19, 2010 at 23:32, Hugo Palma <[email protected]> wrote: > My suspicions were right. > So, when annotated to generate java bean accessors both default accessors > and java bean accessor methods exist, but the implementation of the java > bean ones just call the default ones. > > So, the best choice is to use the java bean accessors if present because > this way it'll be sure to use any overridden version that might be provided > for any of the accessor methods. > > > On Fri, Mar 19, 2010 at 17:26, Hugo Palma <[email protected]> wrote: > >> You mean both java bean style and scala style getters and setters ? >> I'll have to check what happens when you annotate the property with >> @scala.reflect.BeanInfo, >> i'm not sure if the default getters and setters still exist in that case. >> >> If they do, i'll need to check how the bean accessors are generated to see >> who should take precedence, but i'm guessing it won't make a difference >> because the most obvious implementation is for the generated bean accessors >> to simply call the default ones. >> >> >> On Fri, Mar 19, 2010 at 17:18, Howard Lewis Ship <[email protected]>wrote: >> >>> Sounds fine for me ... just merge the Scala properties into the >>> JavaBeans properties. Do you ever have the case where you have both >>> for the same property name? In such a case, which should take >>> precedence? >>> >>> On Fri, Mar 19, 2010 at 10:10 AM, Hugo Palma <[email protected]> >>> wrote: >>> > Yes, it's just a different naming convention. For a property "name" the >>> > getter would be "name()" and the setter would be "name_$eq()" >>> > >>> > The implementation approach i was thinking was to implement >>> > a addPropertiesFromScala method in to the PropertyAccessImpl class and >>> call >>> > it from the buildAdapter method just like it does now for >>> > the addPropertiesFromExtendedInterfaces. >>> > >>> > On Fri, Mar 19, 2010 at 16:40, Howard Lewis Ship <[email protected]> >>> wrote: >>> > >>> >> What does the Scala property look like? Is it just a different naming >>> >> convention for the getter & setter? >>> >> >>> >> In any case, it probably can be accomplished by extending >>> >> PropertyAccess. If PropertyAccess returns the correct things, then >>> >> PropertyConduitSource will build the right code for property >>> >> expression access. >>> >> >>> >> On Fri, Mar 19, 2010 at 8:38 AM, Hugo Palma <[email protected]> >>> >> wrote: >>> >> > I've recently started developing a Tapestry application using only >>> Scala >>> >> and >>> >> > so far it's been working great. >>> >> > >>> >> > One thing that annoys me a little is the fact that i have to >>> annotate all >>> >> my >>> >> > classes with the @scala.reflect.BeanInfo so that proper bean getter >>> and >>> >> > setters are generated and discovered by Tapestry. >>> >> > What i'd like is to do this in Scala: >>> >> > >>> >> > class MyComponent { >>> >> > var myProperty >>> >> > } >>> >> > >>> >> > and Tapestry would be able to use "myProperty" as a real property, >>> >> because >>> >> > it actually is. It's just that Scala doesn't use the java beans >>> >> convention >>> >> > for getters and setters name. >>> >> > >>> >> > Anyway, i was wondering if you guys agree with adding support for >>> Scala >>> >> > properties into Tapestry or if that's a direction you don't want to >>> take. >>> >> > If you agree with incorporating such change, i'll gladly submit a >>> patch >>> >> with >>> >> > the required change to make this work. >>> >> > >>> >> > Cheers. >>> >> > >>> >> >>> >> >>> >> >>> >> -- >>> >> 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: [email protected] >>> >> For additional commands, e-mail: [email protected] >>> >> >>> >> >>> > >>> >>> >>> >>> -- >>> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >
