You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Troy Cauble <tr...@gmail.com> on 2009/08/09 04:56:05 UTC

Changing a Form's Model

I have the following password confirmation pattern borrowed from WIA

                PasswordTextField p1 = new
PasswordTextField("password").setResetPassword(false);
                docForm.add(p1);
                PasswordTextField p2 = new
PasswordTextField("repeatPassword").setResetPassword(false);
      -->      p2.setModel(p1.getModel());
                docForm.add(p2);
                docForm.add(new EqualPasswordInputValidator(p1, p2));

in a form that gets reused (repetitively in the same page).  This used
to work fine
with a CPM and calling docForm.setModelObject().

I rewrote to pass models instead of objects, changing
    docForm.setModelObject() to
    docForm.setModel(new CPM(new EntityModel(...)))

and got
    "No get method defined for class: ... expression: repeatPassword"
But the other fields work fine, if I comment out the repeatPasswordField.
(My underlying data object has never had a repeatPassword field.)

It works if I call
     cpm.setChainedModel(new EntityModel(....));

instead, but that seems a little non-obvious.  I imagine redoing the
p2.setModel(p1.getModel() would work too.

Q1.  Is the setChainedModel() call the best solution for this case?
Q2.  It's a good thing to pass models, right?  LDM's don't support setObject().
Q3.  In general (not this case), for reusing forms with CPM(EntityM) should I
        replace the CPM or only the EntityM ?

Thanks,
-troy

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Changing a Form's Model

Posted by Erik van Oosten <e....@grons.nl>.
I am glad you got that right :)

If the model has changed, call modelChanged() on the form (and/or the 
form components, not sure). There is no need to again set the model.

Regards,
    Erik.



Troy Cauble wrote:
>>> in a form that gets reused (repetitively in the same page).
>>>       
>> Don't you ever re-use a component! Sharing models/behaviors is fine, sharing
>> components is not.
>>     
>
> Thanks, Erik, but I'm pretty sure we're talking about different things.
> I'm just using components on a page and changing the data.
> (Reusing the form *over time*.)
>
> I have
>
> Page
>    DropDownChoice
>    Form
>       Fields
>
> When an entity is selected with the DDC, the
> form is made visible and filled with the model/data
> of the entity.  When a save button is hit the form
> is hidden and the DDC reset ("Choose one...").
>
> You're not saying the Form should be discarded and rebuilt,
> are you?
>
> Thanks,
> -troy
>
>
>   

-- 
Erik van Oosten
http://day-to-day-stuff.blogspot.com/



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Changing a Form's Model

Posted by Troy Cauble <tr...@gmail.com>.
>> in a form that gets reused (repetitively in the same page).
>
> Don't you ever re-use a component! Sharing models/behaviors is fine, sharing
> components is not.

Thanks, Erik, but I'm pretty sure we're talking about different things.
I'm just using components on a page and changing the data.
(Reusing the form *over time*.)

I have

Page
   DropDownChoice
   Form
      Fields

When an entity is selected with the DDC, the
form is made visible and filled with the model/data
of the entity.  When a save button is hit the form
is hidden and the DDC reset ("Choose one...").

You're not saying the Form should be discarded and rebuilt,
are you?

Thanks,
-troy

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Changing a Form's Model

Posted by Erik van Oosten <e....@grons.nl>.
Hi Troy,

There is no need to set the same model on both password fields. The 
confirmation field can be initialized with its own (dummy) model like so:

PasswordTextField p2 = new PasswordTextField("repeatPassword", new Model()).setResetPassword(false);

This is the same with or without a CPM.

 > in a form that gets reused (repetitively in the same page).

Don't you ever re-use a component! Sharing models/behaviors is fine, 
sharing components is not.

Regarding your other questions:

> Q1.  Is the setChainedModel() call the best solution for this case?

No, just don't share components.

> Q2.  It's a good thing to pass models, right?  LDM's don't support setObject().

Yes. Actually, you could override setObject of a LDM but I can not 
really recommend it as LDM is not set up for using the set object.

Q3.  In general (not this case), for reusing forms with CPM(EntityM) should I
        replace the CPM or only the EntityM ?

See answer to Q1.

Regards,
    Erik.


Troy Cauble wrote:
> I have the following password confirmation pattern borrowed from WIA
>
>                 PasswordTextField p1 = new
> PasswordTextField("password").setResetPassword(false);
>                 docForm.add(p1);
>                 PasswordTextField p2 = new
> PasswordTextField("repeatPassword").setResetPassword(false);
>       -->      p2.setModel(p1.getModel());
>                 docForm.add(p2);
>                 docForm.add(new EqualPasswordInputValidator(p1, p2));
>
> in a form that gets reused (repetitively in the same page).  This used
> to work fine
> with a CPM and calling docForm.setModelObject().
>
> I rewrote to pass models instead of objects, changing
>     docForm.setModelObject() to
>     docForm.setModel(new CPM(new EntityModel(...)))
>
> and got
>     "No get method defined for class: ... expression: repeatPassword"
> But the other fields work fine, if I comment out the repeatPasswordField.
> (My underlying data object has never had a repeatPassword field.)
>
> It works if I call
>      cpm.setChainedModel(new EntityModel(....));
>
> instead, but that seems a little non-obvious.  I imagine redoing the
> p2.setModel(p1.getModel() would work too.
>
> Q1.  Is the setChainedModel() call the best solution for this case?
> Q2.  It's a good thing to pass models, right?  LDM's don't support setObject().
> Q3.  In general (not this case), for reusing forms with CPM(EntityM) should I
>         replace the CPM or only the EntityM ?
>
> Thanks,
> -troy
>
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Changing a Form's Model

Posted by bferr <bf...@juno.com>.
Fragments would allow you to have different markup and markup hierarchy for
each DDC option in case the entity attributes were different.



LazyBoy wrote:
> 
> Yes, a different EM for each DDC option.
> 
> Replacing the form's model is working.
> Replacing the form's modelObject worked before that.
> I'm just trying to understand what the best current practice is.
> 
> What would the advantage of fragments be?
> Creating the fragment on selection or maintaining N fragments?
> 
> -troy
> 
> On Tue, Aug 11, 2009 at 1:56 PM, bferr<bf...@juno.com> wrote:
>>
>> It sounds like you have different entitiy models for each DDC option
>> right?
>> That's why you are replacing the model of the form each time?
>>
>> I think you could try creating a fragment for each DDC option and each
>> fragment would have it's own model.  Then replace the fragment inside the
>> form when the DDC is changed and the "enclosing CPM" would be the one on
>> the
>> fragment and not the one on the form.
>>
>>
>>
>>
>>
>>
>> LazyBoy wrote:
>>>
>>> I have the following password confirmation pattern borrowed from WIA
>>>
>>>                 PasswordTextField p1 = new
>>> PasswordTextField("password").setResetPassword(false);
>>>                 docForm.add(p1);
>>>                 PasswordTextField p2 = new
>>> PasswordTextField("repeatPassword").setResetPassword(false);
>>>       -->      p2.setModel(p1.getModel());
>>>                 docForm.add(p2);
>>>                 docForm.add(new EqualPasswordInputValidator(p1, p2));
>>>
>>> in a form that gets reused (repetitively in the same page).  This used
>>> to work fine
>>> with a CPM and calling docForm.setModelObject().
>>>
>>> I rewrote to pass models instead of objects, changing
>>>     docForm.setModelObject() to
>>>     docForm.setModel(new CPM(new EntityModel(...)))
>>>
>>> and got
>>>     "No get method defined for class: ... expression: repeatPassword"
>>> But the other fields work fine, if I comment out the
>>> repeatPasswordField.
>>> (My underlying data object has never had a repeatPassword field.)
>>>
>>> It works if I call
>>>      cpm.setChainedModel(new EntityModel(....));
>>>
>>> instead, but that seems a little non-obvious.  I imagine redoing the
>>> p2.setModel(p1.getModel() would work too.
>>>
>>> Q1.  Is the setChainedModel() call the best solution for this case?
>>> Q2.  It's a good thing to pass models, right?  LDM's don't support
>>> setObject().
>>> Q3.  In general (not this case), for reusing forms with CPM(EntityM)
>>> should I
>>>         replace the CPM or only the EntityM ?
>>>
>>> Thanks,
>>> -troy
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Changing-a-Form%27s-Model-tp24883888p24922623.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Changing-a-Form%27s-Model-tp24883888p24943857.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Changing a Form's Model

Posted by Troy Cauble <tr...@gmail.com>.
Yes, a different EM for each DDC option.

Replacing the form's model is working.
Replacing the form's modelObject worked before that.
I'm just trying to understand what the best current practice is.

What would the advantage of fragments be?
Creating the fragment on selection or maintaining N fragments?

-troy

On Tue, Aug 11, 2009 at 1:56 PM, bferr<bf...@juno.com> wrote:
>
> It sounds like you have different entitiy models for each DDC option right?
> That's why you are replacing the model of the form each time?
>
> I think you could try creating a fragment for each DDC option and each
> fragment would have it's own model.  Then replace the fragment inside the
> form when the DDC is changed and the "enclosing CPM" would be the one on the
> fragment and not the one on the form.
>
>
>
>
>
>
> LazyBoy wrote:
>>
>> I have the following password confirmation pattern borrowed from WIA
>>
>>                 PasswordTextField p1 = new
>> PasswordTextField("password").setResetPassword(false);
>>                 docForm.add(p1);
>>                 PasswordTextField p2 = new
>> PasswordTextField("repeatPassword").setResetPassword(false);
>>       -->      p2.setModel(p1.getModel());
>>                 docForm.add(p2);
>>                 docForm.add(new EqualPasswordInputValidator(p1, p2));
>>
>> in a form that gets reused (repetitively in the same page).  This used
>> to work fine
>> with a CPM and calling docForm.setModelObject().
>>
>> I rewrote to pass models instead of objects, changing
>>     docForm.setModelObject() to
>>     docForm.setModel(new CPM(new EntityModel(...)))
>>
>> and got
>>     "No get method defined for class: ... expression: repeatPassword"
>> But the other fields work fine, if I comment out the repeatPasswordField.
>> (My underlying data object has never had a repeatPassword field.)
>>
>> It works if I call
>>      cpm.setChainedModel(new EntityModel(....));
>>
>> instead, but that seems a little non-obvious.  I imagine redoing the
>> p2.setModel(p1.getModel() would work too.
>>
>> Q1.  Is the setChainedModel() call the best solution for this case?
>> Q2.  It's a good thing to pass models, right?  LDM's don't support
>> setObject().
>> Q3.  In general (not this case), for reusing forms with CPM(EntityM)
>> should I
>>         replace the CPM or only the EntityM ?
>>
>> Thanks,
>> -troy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Changing-a-Form%27s-Model-tp24883888p24922623.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Changing a Form's Model

Posted by bferr <bf...@juno.com>.
It sounds like you have different entitiy models for each DDC option right? 
That's why you are replacing the model of the form each time?  

I think you could try creating a fragment for each DDC option and each
fragment would have it's own model.  Then replace the fragment inside the
form when the DDC is changed and the "enclosing CPM" would be the one on the
fragment and not the one on the form.






LazyBoy wrote:
> 
> I have the following password confirmation pattern borrowed from WIA
> 
>                 PasswordTextField p1 = new
> PasswordTextField("password").setResetPassword(false);
>                 docForm.add(p1);
>                 PasswordTextField p2 = new
> PasswordTextField("repeatPassword").setResetPassword(false);
>       -->      p2.setModel(p1.getModel());
>                 docForm.add(p2);
>                 docForm.add(new EqualPasswordInputValidator(p1, p2));
> 
> in a form that gets reused (repetitively in the same page).  This used
> to work fine
> with a CPM and calling docForm.setModelObject().
> 
> I rewrote to pass models instead of objects, changing
>     docForm.setModelObject() to
>     docForm.setModel(new CPM(new EntityModel(...)))
> 
> and got
>     "No get method defined for class: ... expression: repeatPassword"
> But the other fields work fine, if I comment out the repeatPasswordField.
> (My underlying data object has never had a repeatPassword field.)
> 
> It works if I call
>      cpm.setChainedModel(new EntityModel(....));
> 
> instead, but that seems a little non-obvious.  I imagine redoing the
> p2.setModel(p1.getModel() would work too.
> 
> Q1.  Is the setChainedModel() call the best solution for this case?
> Q2.  It's a good thing to pass models, right?  LDM's don't support
> setObject().
> Q3.  In general (not this case), for reusing forms with CPM(EntityM)
> should I
>         replace the CPM or only the EntityM ?
> 
> Thanks,
> -troy
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Changing-a-Form%27s-Model-tp24883888p24922623.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org