FWIW, for FormComponentPanels I often have an empty implementation
of updateModel() and either have a wrapper method to add validators
for those (abstract) sub-component, or redefine convertInput() to
construct a proper object from
nestedFormComponent.getConvertedInput() to make validators work on
them.
Works most of the time like a charm; except those 0.001% where I
really need to have (a) a proper conversion/validation on the
FormComponentPanel level and (b) full support of AJAX
onchange-updates for the sub-components. Then it get's hairy... :-)
Cheers,
Joachim
On 02/12/16 18:29, Sven Meier wrote:
> 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
>>>>>
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod, Roedermark, Germany
Email: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
