> Although access to the other components by navigating the component
> tree is guaranteed to work, I take your point that it makes the logic
> of this "check" type validator more fragile. Here's a technique to
> consider that might alleviate the issue somewhat:
Yes that was my point. Wouldn't you agree?
> * Use the "binding" attribute to bind all your input components to
> corresponding properties in the backing bean (Creator will do this
> for you automatically :-).
>
> * Instead of implementing validators as separate classes, implement
> them as a method binding to a method in the same backing bean:
>
> <h:inputText binding="#{mybean.username}"
> validator="#{mybean.checkBizRules}"/>
>
> which would bind to a method like this:
>
> public void checkBizRules(FacesContext context, UIComponent
> component, Object value)
> throws ValidatorException;
>
> Discerning viewers will note that this is exactly the same method
> signature as the Validator.validate() method, except for the method
> name.
>
> Within checkBizRules(), you'll have access to the actual components by
> name (that is, by the property names you bound them to) without having
> to navigate the structure of the component tree. You're guaranteed,
> by virtue of the lifecycle, that all the submitted values have been
> set first ... although you're not guaranteed that all the other
> validators have fired yet.
Nice solution. I thought about binding but for some reason I skipped
over binding to the backing bean (and also making the same backing
bean a validator.) Usually I see the use of the binding attribute to
bind components to other components. This obviously limits you to
pairs of components bound together and that was what gave me the idea
of a "glue" component to bind everything together.
I never thought of binding a component to a backing bean. Why would I
when I can use EL to get the values *out* of the backing bean? Well,
you've given me an answer.
> Hmm ... sort of along the lines of what <x:saveState> does for state
> saving? I think it might be simpler to use the explicit bindings
> approach outined above.
Yes you are right. You approach is much better. If binding was
limited to UIComponent then my approach would be the right one but
since you can bind to anything, your approach makes more sense.
Thanks again for the excellent advice.
> Craig
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
