There are plenty of cases where there isn't much risk and where using
CompoundPropertyModels is just convenient and leads to nicer readable
(imho) code. I use those models quite a bit, and I like them. I use
plenty of other (custom LDMs mainly) as well though.
Eelco
On Thu, Jun 5, 2008 at 10:29 AM, James Carman
<[EMAIL PROTECTED]> wrote:
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
