On 8/2/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> We're having some difficulties writing complex validators in JSF. In
> many cases we have a field whose validation depends on the value of
> another field. JSF doesn't really handle this situation very well in
> the processValidations phase because you don't have access to the
> other values.
>
With a bit of effort, you can gain access to the *submitted* values of
other components (because the validator receives a reference to the
component being validated and the FacesContext, so you can navigate
around the tree) ... but, your fundamental issue is that Process
Validations happens before Update Model Values, right?
> I've run into this problem with dialogs where I'd really like to be
> able to access #{dialog.data} inside my validator but its not updated
> yet. It seems like Shale might be able to provide a lifecycle
> "add-on" here that would help developers deal with this shortcoming.
>
Interesting thought ... it sounds like you want a "business rules
validation" phase in between Update Model Values and Invoke
Application, which coud examine the converted and *updated* state of
all the components. That is definitely achieveable using phase
listeners. Maybe something along the lines of this in ViewController?
/**
* <p>Callback that is invoked during a postback, in between the Update
* Model Values phase and the Invoke Application phase of the
* request processing lifecycle. Use this callback to examine the
* overall state of the updated component values, applying business
* rules that should be enforced no matter which action was submitted
* by the user. If business rule validations are found, throw a
* <code>ValidationException</code> containing a <code>FacesMessage</code>
* that describes the failure.</p>
*/
public void validate() throws ValidatorException;
One fly in the ointment, though, is the fact that the values each
component is bound to *have* been updated, even though the business
rules are going to flag a failure. If those updates have side
effects, your application will need to undo them.
Of course, you can accomplish the same thing by calling a validate
method like this yourself at the beginning of each action handler
(which also lets you apply different business rules, say, to a
"Cancel" versus a "Save"); but you're going to suffer the same problem
of having to undo the updates that occurred. It would seem safer to
deal with the submitted values during Process Validations instead.
> sean
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
