>From: Ryan Wynn <[EMAIL PROTECTED]> > > On 2/13/06, Craig McClanahan 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?
I think that's what the 1.1 spec says. I assumed that the createComponent(ValueBinding, FacesContext, componentType) would do that? If not, it would be simple to add that extra logic. Gary
