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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
