On 8/9/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> > 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?
It depends on whether you can make assumptions about common parentage
... but UIComponent.findComponent() is pretty good about navigating
hierarchies without precisely understanding their structure.
>
> > * 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.
>
Right ... that would definitely be a restriction of tying components
together that way.
> 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.
>
There actually is an answer to this question that is unrelated to the
validation use case.
Consider the JSF standard <h:dataTable> component (or any other table
component that allows pagination). Now, let's implement a "next page"
or "previous page" pagination button. That involves writing an action
method to do the following:
* Acquire a reference to the UIData component itself.
* Get the "first" and "rows" property values.
* Increment or decrement the "first" property value,
and update it on the component instance.
* Return null to cause this page to be redisplayed.
The first step is a heck of a lot simpler if the data table component
is itself bound to the backing bean ... you can just refer to the
instance variable directly.
And this concept generalizes to pretty much any use case where you
want to programmatically modify the properties of a few components, or
even dynamically add some components to the tree ... and then
redisplay the same page again.
Craig
> > 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]
