Sunday, October 12, 2008

component trees (views)

I was reading about the differences between binding a UI JSP component to a UIComponent property in your backing bean using the binding property on the JSP component, and value-binding your JSP component to a model-level bean property in some class somewhere.

Well I figured out a couple of things:
1. One difference: if you believe in MVC you should keep your view-level stuff sepparate from your model level stuff. So using binding is better than value binding if you have the option.
2. The binding connection gets the values into the backing bean properties in phase two of the JSF lifecycle, where as it is the model update phase (phase 4 or 5) before you get it updated if you have a value binding connection. At least I think so...
3. From what I read it sounds like if the JSF container is in the process of rendering a UIComponent, that is no guarentee that any other UIComponent in that page's view has been put in the view (component tree) or rendered! This is for JSF 1.1. In JSF 1.2 it sounds like they have made it so that if rendering is occurring you can guarentee that all the view has been built already! I wonder if in JSF 1.1 a render of a particular UIComponent alway implies that the component has been inserted into the tree. It seems as if you would have to construct a tree in a way that would allow later traversal. And not just random nodes...although I do remember algorithms for BTree insertion that allowed you to insert random nodes and have them end up in a reasonable order...so who knows.