I always set 3rd party jar logging to error and I wouldn't want to see that. It seems more like debug if anything. The tree component created the id string it parses based on the TreeNode it got. If it isn't there when it looks for it later it's not the tree component's fault. You can log a debug message so end user's who want to test their use of the component can turn on debug logging for it and see it.
I'm doing a JSF crash course this weekend with the o'reilly book so if I find anything out about using a bundle to associate the message key for the component I'll let you know. ----- Original Message ----- From: "Sean Schofield" <[EMAIL PROTECTED]> To: "MyFaces Discussion" <[email protected]> Sent: Friday, April 01, 2005 9:27 PM Subject: Re: tree2 deleted nodes > > How about just FacesContext.addmessage("The selected item no longer > > exists."). Then the end user can display the message or not. Just because > > one branch or leaf was deleted doesn't mean the tree is gone (and even it it > > was that's a use case). The above is way to handle errors recommended in the > > J2EE Tutorial JSF chapters. > > That might be a good option. What about a message in addition to a > log statement. This might be the kind of thing the developer would > care about as well (if its not expected.) > > > I have to read up on bundles but I'd think there was a way to add a message > > as a key so an end user can just put it in their bundle and get a custom > > message out. > > I don't know much about it either. But no better time to learn than > the present. Also, I believe you can associate the message with a > specific component. > > > The reason that I encountered it is that I wrote example code that randomly > > generates the tree every time the page loads so I could test whether or not > > the tree would survive in my actual application. > > Well that explains it. I figured there was a logical explanation :-) > > > Rob > > sean
