Okay, long story short.
I'm gonna be -1 on removing model utility methods and default model
slot from component until you suggest a clean and transparent way to
support
- compound (inherited) models
- component assigned models
- automatic detachment
Just because you don't use these features it doesn't mean there are
not users who do.
There is convenience, removing bloat and just crippling the API. And
there's difference between these.
Don't take me wrong, I don't mind removing the *default* methods from
components, but not in a way that is going to sacrifice any of the
mentioned functionality.
On Thu, Jul 3, 2008 at 5:32 AM, Timo Rantalaiho <[EMAIL PROTECTED]> wrote:
> 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.
Sure, mind sharing how?
>
> 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 :)
>From component where? ComponentUtil? Component has a very strong and
complicated contract. There are lot of methods in component, but there
are reasons for it. There are parts like rendering though that might
need to be cleaned up.
>
>> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
