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]
