On Wed, 02 Jul 2008, Matej Knopp wrote:
> I still don't see what's wrong with GenericPanel. It's certainly much
> easier to type than ModelContainingPanel.
Nothing wrong with that either, it's just very generic :)
There are a lot of ways of making use of generics in a
component besides just adding the type parameter bound to
the type parameter of the model of the component.
I mean, if you have
public FooPanel extends GenericPanel<Foo> {
public FooPanel(String id, IModel<Foo> model, IModel<List<Bar>> bars) {
...
}
...
}
it's not so much more generic than
public FooPanel extends Panel {
public FooPanel(String id, IModel<Foo> model, IModel<List<Bar>> bars) {
...
}
...
}
> I strongly disagree. There are good reasons for Wicket to bind model
> and component together and I think what we have in 1.4 right now is a
> balanced compromise.
I'd be glad to hear more on this! For now, I imagine that a
lot of stuff that the Component IModel dependency exists for
could be done in other ways.
And there is some functionality in there that Wicket might
be better without. For example, onModelChanged / Changing
things become tricky when you share the same model between
different instances. And when using setModelObject() with an
object that is equal to the current model object, but a
different instance (such as a Hibernate-persisted object
bound to the correct session), you have to either do
getModel().setObject() or change the model comparator.
Again, I'm just exploring, and perhaps overlooking
something.
> Also if we don't provide the convenience classes
> people will bound to write their own (because it's the only reasonable
> way to migrate project that already uses generics).
That's true, I just thought it would be no big deal and only
affect the earliest 1.4 adopters (or those still converting
from 2.0 if there are any left) (sorry :)). I had in mind
that if we then remove those convenience classes in 1.5,
they would have to move to the user codebases anyway, but
maybe 1.4 -> 1.5 will not be such a common migration path
because of API breaks.
> I don't buy this. Our components have a lot of methods, but most of
> them are not part of public API. I plan to prefix those methods with a
> common prefix for 1.5 so they don't confuse regular users. But I
> really don't see how removing four methods (*defaultModel) improves
> our api.
It would be better (altough harder) to move responsibilities
away from Component to other classes, which could be then
marked as not being a part of the public API. When you do
the rename I'll be happy to do a spike of moving some of the
renamed stuff away from Component altogether :)
> Models have always been conceptually bound to component. Right now the
> problem of our API is not that we have a model slot in component. It
> is that we have exactly one model slot. This doesn't work well for all
> components, since some don't need model at all and some need more than
> one.
Yeah, if we cannot get rid of the default model handling
(which I still hope to be possible), at least a more
flexible abstraction (IModelsContainer?) might be good.
> esier. Now thinking about it, the name should really suggest that
> there is one model per component. Maybe PanelWithModel could be the
> name after all :)
PanelWithExactlyOneModelInTheDefaultSlotAndHoldingAnObjectOfTheSameTypeAsTheTypeParameterOfThisComponent
:)
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
