Hi Patrick,
sorry for the confusion.
>Does this objection have any consequences for my implementation?
Wicket validates all values *before* they are written into the models.
So validators always validate the converted input only.
You have the following options:
- IValidator, validates the converted input of a single field
- IFormValidator, validates the converted input of multiple fields (but
has to be attached to the form)
- FormComponentPanel, same as IFormValidator - pro: does not need to be
added to form, cons: have to override convertInput() and/or updateModel()
- validate your domain objects after the models have been updated, e.g.
from onClick().
Perhaps you create a quickstart, so we can make sure that we're talking
about the same option.
Regards
Sven
On 15.02.2016 12:35, Patrick Davids wrote:
Hi Sven,
> Yes, the converted values haven't been written yet.
Does this objection have any consequences for my implementation?
For me, it semms it is working now... so I think, there is no need to
me to additionally override
> @Override
> public void validate() {
> // validate nested convertedInput which is *not* yet written
>
> if (nestedFormComponent.getConvertedInput() ...) {
> error(...);
> }
> }
Should I pay any special attention for an unusual behavior?
Should I test a special case?
Whats the risk, leaving my impl. as it is?
Or am I quite save?
kind regards
Patrick
Am 12.02.2016 um 18:29 schrieb Sven Meier:
Hi again,
now I see what you meant:
Yes, the converted values haven't been written yet.
I was writing my example off the top of my head :). Validators won't
help here, you'll have to do validation by hand instead:
PersonPanel extends FormComponentPanel {
@Override
protected void convertInput() {
// converted input is just the current model object
setConvertedInput(getModelObject();
}
@Override
public void validate() {
// validate nested convertedInput which is *not* yet written
if (nestedFormComponent.getConvertedInput() ...) {
error(...);
}
}
Regards
Sven
On 12.02.2016 18:17, Sven Meier wrote:
Hi Martin,
>The modelObject should be the one before the form submit,
it should be the same one which all nested formComponents are
changing. I can't think of a case where this shouldn't hold.
>Because Form#updateModels() is called after the conversion and
validations.
>By calling the line above you basically ignore the submitted
parameters.
The containing 'normal' formComponents have written the parameters
into their models, which are changing properties of the 'main'
modelObject.
For the FormComponentPanel the following is a noop:
setConvertedInput(getModelObject());
...
updateModel();
I'm doing it this way, because the formComponentPanel hasn't anything
to convert actually, its model object stays the same.
Regards
Sven
On 12.02.2016 17:44, Martin Grigorov wrote:
Hi Sven,
On Fri, Feb 12, 2016 at 12:08 PM, Sven Meier <[email protected]> wrote:
Hi,
Is it a good idea to implement such a case extending
FormComponentPanel,
or is FormComponentPanel for other purposes?
usuallly a FormComponentPanel is used when you want to combine the
input
of several formComponents into a single model object, e.g.
MultiFileUploadField and DateTimeField.
But you can also use it for validation of whole model objects:
PersonPanel extends FormComponentPanel {
protected void convertInput() {
// converter input is just the current model object
setConvertedInput(getModelObject();
The modelObject should be the one before the form submit, no? Because
Form#updateModels() is called after the conversion and validations.
By calling the line above you basically ignore the submitted
parameters.
I am missing something in your idea. What is it?
}
}
Form f = new Form(...);
PersonPanel personPanel = new PersonPanel(...)
personPanel.add(new XYValidator()); // <-- a validator that
validates the
'converted' person
f.add(personPanel);
Have fun
Sven
On 12.02.2016 11:17, Patrick Davids wrote:
Hi all,
I would like to implement some kind of modular form components.
So, a developer is able stick together a form to save e.g. person
data
and adress data with different panels containing the particular
needed
input fields (textfield, selectboxes etc).
Form f = new Form(...);
f.add(new PersonFormComponentPanel(...));
f.add(new AddressFormComponentPanel(...));
Both, PersonFormComponentPanel and AddressFormComponentPanel are
simple
panels, now, and it is working so far.
Now, I have a special use-case, which needs to add an
AbstractFormValidator to the form.
Not to bypass the inner required textfields validations of
PersonFormComponentPanel, I can implement
FormComponent<?>[] getDependentFormComponents(){...}
of the AbstractFormValidator.
BUT, it requieres to return FormComponents, not simple panels.
So, my idea was, just changing the implementation of
PersonFormComponentPanel extends Panel to PersonFormComponentPanel
extends
FormComponentPanel, so the entire PersonFormComponentPanel acts as
FormComponent to be able to fullfill the FormComponent<?>[]
getDependentFormComponents(){...} return value.
Unfortunately this is not working, and I dont know why...
My getInnerMostModel() of the PropertyResolver is always null and
the
formcomponents model-update does not succeed /
WicketRuntimeException.
Maybe it has something todo with the need to implement
setConvertedInput() / getConvertedInput() which is mentioned in the
javadoc
of FormComponentPanel?
I'm not sure about that... maybe someone can help here?
So... these are my questions:
Is it a good idea to implement such a case extending
FormComponentPanel,
or is FormComponentPanel for other purposes?
How can I achieve the binding of the dependend formcomponents to the
AbstractFormValidator, without exposing the inner formcomponents of
the
PersonFormComponentPanel by providing a method like
PersonFormComponentPanel.getAllInnerFormComponents()?
Am I able to keep the idea of extending FormComponentPanel by
implementing getConvertedInput(), but how to to that right?
Thanx a lot for help
kind regards
Parick
---------------------------------------------------------------------
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]
