By the way, why that ?
Compatibility. The more open to subclassing a component is, the harder
it is to keep it backward-compatible.
Well, that's a good point. It's always about keeping the balance ...
Exactly. I was saying that components provided by Tapestry aren't
meant to
be subclassed, but the ones you write can be. Tapestry's components use
subclassing too: AbstractField, AbstractTextField, etc. Maybe Tapestry
should have some more of them, just like an AbstractSelect.
That would nice!
If you have common logic in different components you should move it
into a service...
Of course! But I'm talking about common component logic like tapestry
already provides like Select or Grid.
No application releated logic or components which are entirely new.
I have created an AbstractSelect which is the baseclass of many of my
Subclasses now, but this (my) AbstractSelect is unnecessary and repeats
just the code of Select with some minor changes.
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
