On 2/13/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > Interestingly, that parallels a corresponding issue with the JSP rendition > of JSF components in JSF 1.0/1.1 ... if you have a property set in a tag > attribute, AND you set it in code, which wins? For JSP pages, we went round > and round on this, but decided ultimately that the JSP page author's > expectation that the attributes he or she sets in the page should win > outweighed the surprise that the Java developer is going to have when his > change doesn't seem to show up. Note that this ONLY applies when the > component tree is being first produced, and I haven't looked inside 1.2 yet > to see how the changes there (even with JSP, the component tree is now built > up in total, more like what Clay does already) have affected this. > > But the point of the rambling paragraph above :-) is that we should look at > how the corresponding concept works with JSP rendering, and then either > deliberately decide to match it or differ with it.
In my case I am providing the binding attribute merely for the convenience of later being able to access the component easily in the managed-bean as opposed to wanting to customize it in any way. I personally would rather set component properties outside the code and therefore would prefer the designer wins approach. But I can see that some might like to manipulate the components in java. Actually, I was under the assumption that I didn't even NEED to actually provide an instantiated component for binding, but that the JSF container would create it for me and link it to my managed-bean. I noticed that currently if I do not create the component myself I get a null-pointer exception. Was I wrong in assuming that the container would instantiate for me?
