On Fri, 21 Jan 2005 17:30:07 -0500, Sean Schofield <[EMAIL PROTECTED]> wrote: > > * To transparently listen to *all* the events, one can gain an > > inspiration from understanding how event firing is actually done. > > A component that wants to fire an event will call (on itself) > > the queueEvent(FacesEvent) method. The default implementation > > of this calls queueEvent() on the parent component, and so on up > > to the UIViewRoot at the root of the tree, which does the actual > > broadcasting later. If you had a parent custom component around > > the form, or a custom form component itself, it could "notice" all the > > value change events that were being emitted and do something > > interesting with them. > > What if I had a custom form component along with a class that > decorates UIComponent? In my form component I could get override > queueEvent and wrap the source of the event with my decorating class.
I'm not quite sure in what context you are using the term "decorates". JSF standard processing is going to walk up the parentage hierarchy, *from* the component emitting the event *to* the UIViewRoot. Therefore, unless you actually replace the component in question, in the tree, this walking isn't going to see your decorating separate component. > > The decorating class would just delegate to the decorated instance for > everything but the broadcast method. The broadcast method would > notify the form's value change listener first and then call the > "super" method. > > What do you think of that approach? Is there a problem wrapping the > components in the tree (as long as the decorator extends UIComponent)? See above ... you would have to replace the "real" component with your decorating one, and that seems like a significant distortion to what the user originally constructed. > > Thanks, > > sean > > > Craig > Craig
