This might also screw up stuff like CompoundPropertyModel, no? We
discussed this a bit on ##wicket.
On Thu, Jun 5, 2008 at 11:44 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> i didnt mean the memory slot, i ment the actual default model each
> component can have. if i can write something like this:
>
> add(new webmarkupcontainer("foo") {
> private imodel<person> model;
> protected void isvisible() { return model.getobject()!=null; });
>
> then i am perfectly happy. notice how there is no explicit ondetach()
> to detach the model. also notice how not having a default model slot
> really removes the need for typing the component itself, i can
> implement my own typed getmodel() easily. the only thing that breaks
> here is wrapping since we no longer have a setmodel...something to
> think about
>
> -igor
>
> On Thu, Jun 5, 2008 at 12:53 AM, Johan Compagner <[EMAIL PROTECTED]> wrote:
>> like matej already told you
>> There is no default "slot" or field..
>> A component with no model doesnt have a a slot what so ever.
>>
>> johan
>>
>>
>> On Wed, Jun 4, 2008 at 11:34 PM, Igor Vaynberg <[EMAIL PROTECTED]>
>> wrote:
>>
>>> like i said, i dont mind removing the default slot if we add nice
>>> automatic detachment for fields.
>>>
>>> -igor
>>>
>>>
>>> On Wed, Jun 4, 2008 at 12:23 PM, Eelco Hillenius
>>> <[EMAIL PROTECTED]> wrote:
>>> > On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg <[EMAIL PROTECTED]>
>>> wrote:
>>> >> i dont think it exposes anything, or that anything is flawed. the
>>> >> component provides a slot for a default model - it is there totally
>>> >> out of convinience. i think what is flawed here is that we tied the
>>> >> two types via generics.
>>> >
>>> > It depends on how you phrase things. It is a fact that currently
>>> > models and components are tightly bound because of 'getModelObject'.
>>> >
>>> > The main issue is that with 1.3 you can simply omit the model, whereas
>>> > with generified components the choice to not use a model is explicit
>>> > (whether you use void, or an annotation to ignore warnings). Very
>>> > annoying if you ask me, and it triggered me to think that this is
>>> > another hint that the one-one relationship between components and
>>> > models like we have now is somewhat flawed. I'm not saying it totally
>>> > stinks and that we should get rid of it tomorrow, just that it is
>>> > something we might rethink. You know I'm a fan of rethinking stuff ;-)
>>> >
>>> > 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]
