Hi Michael, we've also stumbled over private/final fields in components in the past.
I don't know the actual reason, but I'm guessing it simply was a design choice made long ago and never changed. Going forward, maybe many (or maybe all?) of the core components should be easier to extend by making properties and methods protected instead of private. This would especially be helpful in cases where copying isn't possible because the component uses more non-public/non-protected types and stuff. Personally, I'd like to open up even more parts of the core components. For example, last week, I needed to affect the @BeginRender of AbstractTextField, but not all steps are available via a protected method. However, fully opening up the components requires a uniform scheme, similar to how the rendering phases are well-defined. This way, extending any component would become straightforward, and custom components would behave as expected. Still, making the parameters protected seems sensible and shouldn't introduce any issues, except for already existing custom replacements that extend the original. Cheers Ben On Mon, Apr 22, 2024 at 3:19 PM Michael Helbig <mich...@michael-helbig.de> wrote: > Hi > > i am using an extension for the Grid Table from Tapestry Core by some > own Developed additional Features (eg. Download, Customizable Column > Selection, etc.). The initial plan was to use an ExtendedGrid Class by > extending the Superclass Within the Core LIbrary Grid.java. Due to the > fact the Parameter Within the Grid.java class, are configured private > final ...., there is no chance to use the information. By changed the > part to for example like this: > > Original > > @Property > @Parameter(required = true, autoconnect = true) > private final GridDataSource source; > > Could be: > > @Property > @Parameter(required = true, autoconnect = true) > protected GridDataSource source; > > all "Extensions" Are able to access the information without further > impacts. Currently the Workaround is to use a "Copy" of Grid.class, > changing the attributes to protected, with this approach other available > Components using Core Grid classes could not be mixed. > > Is there a Reason for having the Values final ? Could this be improved > by using protected ? > > Would be interested in hear your ideas on that ? > > Michael > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
