Hi Juan,

> should i read "how to do smart questions" of eric raymond?

:)

The pattern that we use in our company (I think tsvetelin specified it
fully) is applicable to your case and I think resolves similar issues in
general:

We view validation to consist of two phases:
 - Field validation
 - Group validation

Field validation is performed when the validity of a field is dependent on
itself and on itself only. It can thus be performed immediately when the
field's value is available, even if the other fields have not been handled
yet.

Group validation is performed when the validity of a field depends on
conditions not directly related to the field value (e.g. what button has
been pressed, as it is in your case), or when the validity of two fields is
related (e.g. the start date has to be before the end date). Group
validation can then be performed only when all form values are available,
and the context of the form is clear (e.g. which button has been pressed).


To map this to Tapestry:
  - The standard Tapestry field validation mechanism maps to the Field
validation phase. It is perfect for validating individual fields, but it
cannot handle more complex situations.

  - The Group validation is implemented using a custom code and is invoked
within formSubmit(). Any errors located using it can be reported to the
form's delegate in the usual manner (delegate.setFormComponent(...);
delegate.record(...);). From the view point of the user the result is that
Field and Group validation errors appear the same.


To go back to your case, the verification of the fields that depend on the
button clicked would occur in the Group validation phase.


I hope this helps,
-mb


-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Juan
Alvarez
Sent: Friday, December 06, 2002 4:47 PM
To: [EMAIL PROTECTED]
Subject: Re: [Tapestry-developer] Validation beans in the listener
method


should i read "how to do smart questions" of eric raymond?

On Thu, Dec 05, 2002 at 11:48:55AM -0500, Juan Alvarez wrote:
> I am still trying to do the smae thing of the others mails:
>
> "I have one form, this form have two submits, and i want the
> restrictions of some fields in the form are different for different
> submits"
>
> I this moment, I try with this:
>
> In one listener i get the reference to the bean who has the restrictions
> specified in the descriptor, and modified the value of the required
> property.
>
> public void update(IRequestCycle cycle)
>   {
>     StringValidator validatorRegion = (StringValidator)
getBeans().getBean("validatorRegion");
>     validatorRegion.setRequired(false);
>   }
>
> In other listener, i did something similar but with different
> restrictions.
>
> public void insert(IRequestCycle cycle)
>   {
>     StringValidator validatorRegion = (StringValidator)
getBeans().getBean("validatorRegion");
>     validatorRegion.setRequired(true);
>     validatorRegion.setMinimumLength(10);
>   }
>
> And other listener, do nothig with the validator.  So the applied
> restrictions are the restrictions of the descriptor.
>
> But the behavoir i expect never occurs.  Because the validation of the
> errors (and his respective tracking) occurs before the listener method
> is called.
>
> Is a good feature request, a possibility to each listener have to
> methods associated.  One before the validation occurs and the other one
> similar to the actual behavior.
>
> Or exist other possibility?
>
> TIA
>
> --
> Juan Alvarez                                   Fluid Signal S.A.
> mailto:[EMAIL PROTECTED]        http://www.fluidsignal.com/
> Key fingerprint: 15C4 0986 A174 862A B607 8EEA 934F 8649 07E2 EA40
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Tapestry-developer mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/tapestry-developer

--
Juan Alvarez                                     Fluid Signal S.A.
mailto:[EMAIL PROTECTED]        http://www.fluidsignal.com/
Key fingerprint: 15C4 0986 A174 862A B607 8EEA 934F 8649 07E2 EA40


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer

Reply via email to