On Mon, 2004-04-19 at 17:48, Joerg Heinicke wrote:
> Marc Portier <mpo <at> outerthought.org> writes:
>
> > I do propose:
> > - some refactoring of the kind
> > - introduce more granular methods
> > (e.g. to call parseValue() in stead of getValue() in all occasions
> > where the return is ignored anyway?)
>
> I found another reason that more granular methods are necessary:
>
> I have a field with a selection list and a submit button. The field is optional
> required based on the submit, i.e. if the submit button is pressed there must be
> something selected:
>
> <wd:field id="event">
> <wd:label><i18n:text key="events"/></wd:label>
> <wd:datatype base="string"/>
> <wd:validation>
> <wd:javascript>
> if (form.submitId == 'invoke' && widget.value == null) {
> // add ValidationError
> return false;
> }
> return true;
> </wd:javascript>
> </wd:validation>
> </wd:field>
> <wd:submit id="invoke" action-command="invoke" validate="false">
> <wd:label><i18n:text key="action.invoke"/></wd:label>
> </wd:submit>
>
> Problem: readFromRequest() causes validation on all widgets in their order in
> the form definition.
Which version are you using? I thought Sylvain fixed this a couple of
days ago.
> But readFromRequest() also causes the setting of
> form.submitWidget. So form.submitWidget is not set yet if the above much
> shortened custom validator is evaluated. I have to put the field definition
> 'event' to the end of the form.
>
> More granular methods help to solve the problem: 1st run through form model
> readFromRequest() -> also set form's submitWidget. 2nd run validate().
This separation has always been there (modulus bugs), exactly for your
use case.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
