On Thu, 30 Dec 2004 09:51:49 -0500, Sean Schofield <[EMAIL PROTECTED]> wrote: > A major stumbling block for me with JSF is how the implementations all > seem to "munge" the id attributes of my JSF tags. I'm assuming this > helps with constructing the component tree and mapping the posts to > the right components, but does it have to be this way? > > Both MyFaces and the RI change the id attribute. Couldn't they just > change the name attribute? Isn't that the only thing that is sent via > POST? We have tons of javascript that use the getElementById method > and this would be a problem changing it.
The name attribute is deprecated on (nearly) all elements in XHTML, so that wouldn't be a good answer. The reason that "id" values are calculated is that XHTML requires all "id" values in the rendered page to be unique. Therefore, it is up to the render kit you are using to ensure that this restriction is met -- which it does by prefixing with the id of the closest surrounding NamingContainer (and on up the tree) -- plus, complex components like UIData can get involved in the calculation process to create unique identifiers for looping situations. Note that, without the ability to generate component ids, you would not be able to do what UIData does in rendering multiple rows from the same child components. The key challenge for using JavaScript is knowing what the identifier of a component will be. There is some work going on in the JSF 1.2 area to improve this, but the key thing to know is that the standard renderers all call UIComponent.getClientId() to acquire the "id" value to be emitted. You can do the same thing as you construct the call to your JavaScript functions. Craig
