> Actually, there *is* an important server side use of the clientId > value -- it also becomes the name of the request parameter used to > decode the values of submitted input fields. Indeed, this is why the > decode and encode functionality was merged into a single API > (Renderer) -- only the code that emits the "id" attribute knows what > the name of the corresponding request parameter will be.
I just figured that out after doing some more intensive research on the JSF lifecycle. This shouldn't be a problem though because the same renderer that provides the customized "id" attribute can be used to decode it as well. Right? > You should also note that, even if you added something like "directId" > on the MyFaces extended components, using such a component would fail > inside a UIData (or any similar component) that renders more than one > element from the same component -- the fact that the standard > components use clientId is what lets UIData get involved in the id > assignment process (since UIData is itself a naming container). I figured as much. Well, is there anything we could do to get around this? Couldn't we set the directId/styleId attribute using an index like in Struts? So a directId of "fooItem" would yield fooItem[1], fooItem[2], etc. I'm thinking this is within the realm of possibility. I wasn't sure whether you were pointing out a potential pitfall or whether you fealt this was not feasible. > Craig sean
