You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Robert Zeigler <ro...@scazdl.org> on 2008/03/05 19:53:05 UTC
T5: adding accessors back to corelib components?
I know that we have the shiny new @GenerateAccessors annotation. But
there are some situations where, at least for the corelib components,
having the trusty old public methods might be a "good thing". For
component parameters, using GenerateAccessors probably isn't a deal
breaker since a containing component can supply the parameter value,
and can therefore access the parameter value.
But there component properties that we should perhaps think about a
little more before delegating accessor generation to bytecode
manipulation. The currentPage property of the Grid component comes to
mind. It should be, and used to be, possible to programatically
manipulate this value. But with @GenerateAccessors, the current page
is known only to the Grid component. Providing your own
GridDataSource won't solve the issue, either, since the view of
"currentPage" that "prepare" provides is read-only. (It's not
strictly a view of currentPage; it's the indexes of the set of values
that grid is going to be asking for; but you can calculate the current
page from those values + the rows per page).
So either currentPage needs to be a parameter, or needs to have non-
bytecode-generated public accessors. I'm sure there are other
situations like this. So can we rethink that wild abandon with which
property accessors were abandoned?
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: adding accessors back to corelib components?
Posted by Angelo Chen <an...@yahoo.com.hk>.
Hi Howard,
Property sounds better. This is really a nice feature, is it advisable to
use it with hibernate's entitiy classes?
A.C.
Howard Lewis Ship wrote:
>
> Just struck me, would @Property be a better name for the annotation
> than @GenerateAccessors?
>
> On Wed, Mar 5, 2008 at 4:47 PM, Christian Edward Gruber
> <ch...@gmail.com> wrote:
>> I hear you. I'm hoping to use this all over the place now, since most
>> accessors are boilerplate. Always hated them... or rather the manual
>> creation of them.
>>
>> Christian.
>>
>>
>> On 5-Mar-08, at 16:22 , Howard Lewis Ship wrote:
>> >
>> > I just got a little greedy about removing code and raising the code
>> > coverage % a little. :-)
>> >
>> > Stuck at 93% isn't too bad, though.
>> >
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/T5%3A-adding-accessors-back-to-corelib-components--tp15857551p15864931.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: adding accessors back to corelib components?
Posted by Angelo Chen <an...@yahoo.com.hk>.
Hi,
I started to use this, it really make the code clean, however
GenerateAccessors does not sound right in the class, @Property is definately
better, other languages use this too, borland's Pascal uses property to mean
almost the same thing, might be nice to have this in the 5.0.11.
A.C.
nirvdrum wrote:
>
> I like the name @Property better . . . maps better to the language-level
> construct of properties. @GenerateAccessors, while descriptive, is
> verbose.
>
> I think what be even better is support in the var prefix for arbitrary
> data
> types. I'm hoping with OGNL support forthcoming that this can be
> achieved.
> Then properties that only exist as temporary values for components can be
> yanked from the class altogether.
>
> --
> Kevin
>
>
--
View this message in context: http://www.nabble.com/T5%3A-adding-accessors-back-to-corelib-components--tp15857551p15865307.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: adding accessors back to corelib components?
Posted by Angelo Chen <an...@yahoo.com.hk>.
hi,
This feature is nice, however i think it's good in the page classes, if you
need to refer to those getter/setters from other class, this will not work
as compiler will complain that symbol not found, anyway, it's really a cool
feature as long as used in the right place, I like that.
A.C.
nirvdrum wrote:
>
> I like the name @Property better . . . maps better to the language-level
> construct of properties. @GenerateAccessors, while descriptive, is
> verbose.
>
>
--
View this message in context: http://www.nabble.com/T5%3A-adding-accessors-back-to-corelib-components--tp15857551p15865489.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: adding accessors back to corelib components?
Posted by Kevin Menard <km...@servprise.com>.
I like the name @Property better . . . maps better to the language-level
construct of properties. @GenerateAccessors, while descriptive, is verbose.
I think what be even better is support in the var prefix for arbitrary data
types. I'm hoping with OGNL support forthcoming that this can be achieved.
Then properties that only exist as temporary values for components can be
yanked from the class altogether.
--
Kevin
On 3/5/08 8:59 PM, "Howard Lewis Ship" <hl...@gmail.com> wrote:
> Just struck me, would @Property be a better name for the annotation
> than @GenerateAccessors?
>
> On Wed, Mar 5, 2008 at 4:47 PM, Christian Edward Gruber
> <ch...@gmail.com> wrote:
>> I hear you. I'm hoping to use this all over the place now, since most
>> accessors are boilerplate. Always hated them... or rather the manual
>> creation of them.
>>
>> Christian.
>>
>>
>> On 5-Mar-08, at 16:22 , Howard Lewis Ship wrote:
>>>
>>> I just got a little greedy about removing code and raising the code
>>> coverage % a little. :-)
>>>
>>> Stuck at 93% isn't too bad, though.
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: adding accessors back to corelib components?
Posted by Howard Lewis Ship <hl...@gmail.com>.
Just struck me, would @Property be a better name for the annotation
than @GenerateAccessors?
On Wed, Mar 5, 2008 at 4:47 PM, Christian Edward Gruber
<ch...@gmail.com> wrote:
> I hear you. I'm hoping to use this all over the place now, since most
> accessors are boilerplate. Always hated them... or rather the manual
> creation of them.
>
> Christian.
>
>
> On 5-Mar-08, at 16:22 , Howard Lewis Ship wrote:
> >
> > I just got a little greedy about removing code and raising the code
> > coverage % a little. :-)
> >
> > Stuck at 93% isn't too bad, though.
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: adding accessors back to corelib components?
Posted by Christian Edward Gruber <ch...@gmail.com>.
I hear you. I'm hoping to use this all over the place now, since most
accessors are boilerplate. Always hated them... or rather the manual
creation of them.
Christian.
On 5-Mar-08, at 16:22 , Howard Lewis Ship wrote:
>
> I just got a little greedy about removing code and raising the code
> coverage % a little. :-)
>
> Stuck at 93% isn't too bad, though.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: adding accessors back to corelib components?
Posted by Howard Lewis Ship <hl...@gmail.com>.
True enough, any you see that are missing, please add a JIRA issue.
I just got a little greedy about removing code and raising the code
coverage % a little. :-)
Stuck at 93% isn't too bad, though.
On Wed, Mar 5, 2008 at 10:53 AM, Robert Zeigler <ro...@scazdl.org> wrote:
> I know that we have the shiny new @GenerateAccessors annotation. But
> there are some situations where, at least for the corelib components,
> having the trusty old public methods might be a "good thing". For
> component parameters, using GenerateAccessors probably isn't a deal
> breaker since a containing component can supply the parameter value,
> and can therefore access the parameter value.
>
> But there component properties that we should perhaps think about a
> little more before delegating accessor generation to bytecode
> manipulation. The currentPage property of the Grid component comes to
> mind. It should be, and used to be, possible to programatically
> manipulate this value. But with @GenerateAccessors, the current page
> is known only to the Grid component. Providing your own
> GridDataSource won't solve the issue, either, since the view of
> "currentPage" that "prepare" provides is read-only. (It's not
> strictly a view of currentPage; it's the indexes of the set of values
> that grid is going to be asking for; but you can calculate the current
> page from those values + the rows per page).
>
> So either currentPage needs to be a parameter, or needs to have non-
> bytecode-generated public accessors. I'm sure there are other
> situations like this. So can we rethink that wild abandon with which
> property accessors were abandoned?
>
> Robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org