soo
interface IModelComponent<T>
{
public IModel<T> getModel()
}
and remove getModel/getModelObject methods from component itself?
But then everybody that does use models have to implement it..
On Wed, Jun 4, 2008 at 12:37 PM, James Carman <[EMAIL PROTECTED]>
wrote:
> On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
> <[EMAIL PROTECTED]> wrote:
> >> it all depends, on how and what you're developing.
> >
> > Yeah. I actually use less and less models in the regular way nowadays.
> > I use plenty of panels (the app I work on hardly uses separate pages)
> > that nest other panels in them (typically detail views or dialogs)
> > that reuse models of the parent. But indeed YMMV.
> >
> > Personally, I think the whole generics business exposes that the
> > one-one relation between components and models is flawed. Without
> > generics this isn't much of a problem, just the odd unused member and
> > constructor, but as generics aren't as 'optional' it is all very in
> > your face suddenly.
> >
> > I think on the longer term (post 1.4) we should re-think how models
> > work in Wicket. See if we can find an elegant way to make this more
> > flexible (I'm not in favor of the id based thing someone posted
> > earlier btw) without breaking the whole world.
> >
>
> We discussed this on ##wicket yesterday. I asked why we have models
> on all components and someone pointed out that the main reason was
> about the detach stuff I believe. But, couldn't that be solved by
> having some components that implement something like IModelDriven (or
> IModelBacked or whatever) and the detach logic could apply to only
> those components? Also, someone has pointed out that when they create
> their own components, they sometimes (such as in Palette) have
> multiple "models" that they deal with. Allowing components to name
> their models what they want would be nice, too.
>
> > FWIW, I'm still on the fence when it comes to whether we should go for
> > a full or partial (models only) implementation of generics, though I'm
> > leaning towards partial.
> >
> > Eelco
> >
> > ---------------------------------------------------------------------
> > 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]
>
>
