Johan Compagner wrote:
having IComponent for me means that there are more then 1 Component..
(there are multiply implementations possible then)
So then we have to use IComponent everwhere instead of Component
That means again that it will be a quite large interface, and do we
also then get IMarkupContainer? (and so on and so on)
Why isnt there a javax.swing.IJComponent ?
If this is really a problem then why not drop the "extends Component"
from the
public final <S extends Component> Object visitChildren
and
public static interface IVisitor<T extends Component>
Then you can give anything you want to it.
Problem is that you then have less type checking there. Because that
would make IVisitor completely "generic"
Sure, one has to go for the right level of abstraction
I hit this IFormModelUpdateListener not being a component issue at
almost the same time as I was needing the ListEditor (the one from igor
=> cf http://bit.ly/aSY3zl) to be a FormComponent, which is a pain to do
because of ListEditor extending RepeatingView.
As such, having this 2 notions through some interfaces would have
resolved by 2 issues of the time, hence this mail ;)
On top of that, IFormModelUpdateListener applies only to Component, but
currently could be applied anywhere. Once again an interface looked like
a good solution to tackle that.
For the MarkupContainer question (and the bigger picture), well, indeed
it looks like the logical way to go would be to mimic the current "core"
elements of wicket's components hierarchy with interfaces.
But then, the "worst" interface would be the one for Component, which
based on the 1.5 Component class would at least have 103 methods (I
took the public ones from Component not being already part of some
interface). MarkupContainer, on top of that and with the same rough
methodology, would "only" add 22 methods. For sure, other methods, used
internally, would have to be put as well in some interfaces I guess. On
the other hand, some methods could be grouped on distinct interfaces,
like the ones about feedback messages.
Overall, I feel like it would be quite some work to do but that it would
pay off. Many interface/component could be even more open for
customization and the like, given ever more options to the developers.
Yet it doesn't look utter crazy neither, so the overall return on
investment is unclear. Furthermore, you and other wicket core committers
obviously know better, so, no issue if this idea is dropped.
++
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
