Personally, I find CompoundPropertyModel too "magicy" for my tastes
anyway. Yes, it's very convenient to just use property names for
component ids and it all just works out fine, but that can sometimes
be difficult to understand from a new person's perspective. When
learning a technology, I don't really like it when folk say "just do
it this way; it works; trust me." When I first started using
CompoundPropertyModel, I had these questions (and I'm sure others, but
this is all I can think of right now)?
1. How far up the chain does a Component go looking for something to
base its property expression on?
2. If I have a model on a Component in between my Component and the
Component containing the CPM, will it be smart enough to "skip over"
the intermediate model and travel up to the real one I want?
3. What happens if I change property names!?
Maybe it's just me and I like to know how things work! :) I used to
take apart my toys as a kid and I could never quite get them back
together the way they came.
James
On Thu, Jun 5, 2008 at 1:20 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> yes. thats what i meant by wrapping. when/if we evaluate this we can
> obviously put more thought into what it will effect and how to make it
> all work. right now it was just a two minute idea i had, and it may
> yet forever stay that way.
>
> -igor
>
> On Thu, Jun 5, 2008 at 10:16 AM, James Carman
> <[EMAIL PROTECTED]> wrote:
>> 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]
>>
>>
>
> ---------------------------------------------------------------------
> 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]
