> 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?
Right.
> 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;
Exactly what I was thinking.
> 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.
In my current situation that is not an issue. The dialogs are run in
a popup and are used to update the underlying page. So the database
isn't updated, just the #{dialog.data} which eventually gets dumped
into a javascript return object.
I think I see your point though. The value in the bean will
potentially be changed to an unacceptable value since you are already
done with UpdateModel phase. I guess the previous value is lost by
this point?
> 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.
I'm doing something like this now. On my dialog I have a page with a
next button like this:
<x:commandLink id="next" action="next" type="submit" styleClass="button"
title="Next" forceId="true"
rendered="#{wizard.nextAvailable}"
actionListener="#{wizard.processAction}">
<x:graphicImage value="/images/buttons/next.png"
rendered="true" border="0" style=""/>
</x:commandLink>
Here is the relevant method in the wizard bean ...
public void processAction(ActionEvent event)
{
Status status = (Status) getSessionMap().get(Globals.STATUS);
String viewName = status.getStateName();
Object obj = getBean("jsp$wizard$"+viewName);
if (obj == null)
{
return;
}
String outcome = ((WizardController)obj).check();
HashMap wizardState = (HashMap)getValue("#{dialog.data}");
if(outcome.equals(WizardConstants.SUCCESS))
{
wizardState.put("Valid",WizardConstants.TRUE);
}
else
{
throw new AbortProcessingException();
}
}
I've also extended ViewController interface (WizardController) and
added this new check method to it. There is an abstract
implementation which always returns SUCCESS. So each view controller
that needs check logic can implement its own check logic.
I'm not entirely comfortable with this method but it works. I'm just
wondering if we couldn't standardize it somehow through Shale. It
seems like this would be an issue for more than just me.
> Craig
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
