yuck! :)
-igor
On Wed, Jun 4, 2008 at 2:29 PM, Sven Meier <[EMAIL PROTECTED]> wrote:
> A component could add a behavior for each model it wants to use:
>
> public class ModelBehavior extends AbstractBehavior {
> private IModel model;
> public ModelBehavior(IModel model) {
> this.model = model;
> }
>
> public void detach(Component component) {
> this.model.detach();
> }
> }
>
> public class Label extends WebComponent {
> private IModel model;
> public Label(IModel model) {
> add(new ModelBehavior(this.model = model));
> }
> }
>
> Detachment will then be automatic.
>
> Sven
>
>
> Igor Vaynberg schrieb:
>>
>> 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 <[EMAIL PROTECTED]>
>> wrote:
>>
>>>
>>> and if i store it in metadata ;)
>>>
>>>
>>> On Wed, Jun 4, 2008 at 5:16 PM, Igor Vaynberg <[EMAIL PROTECTED]>
>>> 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
>>>> <[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]
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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]
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> 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]
