> you still have ondetach()...but for convinience we can automatically
> detach any imodel fields, i actually wanted to do this for a while...
>
> -igor
>
> On Wed, Jun 4, 2008 at 8:43 AM, Johan Compagner <
jcompagner@...> wrote:
>> and if i store it in metadata ;)
>>
>>
>> On Wed, Jun 4, 2008 at 5:16 PM, Igor Vaynberg <
igor.vaynberg@...>
>> wrote:
>>
>>> why even have an interface? just detach all imodel fields via reflection!
>>>
>>> -igor
>>>
>>>
>>> On Wed, Jun 4, 2008 at 3:37 AM, James Carman <
james@...>
>>> wrote:
>>> > On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
>>> > <
eelco.hillenius@...> 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:
users-unsubscribe@...
>>> >> For additional commands, e-mail:
users-help@...
>>> >>
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail:
users-unsubscribe@...
>>> > For additional commands, e-mail:
users-help@...
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
users-unsubscribe@...
>>> For additional commands, e-mail:
users-help@...
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
users-unsubscribe@...
> For additional commands, e-mail:
users-help@...
>
>