For the record I have found one more reason why I shouldn't decorate the event. The data table component already wraps original events in its queueEvent method. It does this so that when its time to broadcast the event it knows which component in the data model that event applies to.
The broadcast() method will check the event to see if its an instanceof the private wrapper class. This check would fail if I were to decorate the event with yet another private class. I had given up on that approach a while ago (b/c I had suspected a problem along these lines.) Now I have the concrete proof of how this would fail. sean On Wed, 26 Jan 2005 07:49:22 -0600, Heath Borders <[EMAIL PROTECTED]> wrote: > Well, since you are the one that writes the event listener, you can > impose your own more stringent restrictions than that of the API, if > necessary. > > On Tue, 25 Jan 2005 21:11:34 -0500, Sean Schofield > <[EMAIL PROTECTED]> wrote: > > I've been thinking some more about this idea. I'm starting to think > > that creating a new event will be problematic as well due to the > > decorated nature of the source. Tampering with the source of the > > event might have some undesirable side effects. > > > > One example would be that this would make it possible for event > > handlers to remove the source of the event from the component tree. > > I'm not quite sure why you'd want to do this, but you'd be ruling out > > that possibility. Since the event listeners are expecting to hear > > from the unaltered, original UIComponent that generating the event, > > its probably not best to fool with it. > > > > sean > > > > On Fri, 21 Jan 2005 19:16:32 -0500, Sean Schofield > > <[EMAIL PROTECTED]> wrote: > > > > 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. > > > > > > Actually I was thinking about replacing the event itself (during queue > > > event.) Basically creating a new one, with the decorated component as > > > the source of the event. > > > > > > > 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. > > > > > > The original component tree remains intact. (see above) > > > > > > > Craig > > > > > > sean > > > > > > > -- > -Heath Borders-Wing > [EMAIL PROTECTED] >
