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 tha
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 fragm
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 t
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
>> 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.
(R
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.
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(fa