On Sun, 2 Jan 2005 18:04:27 -0500, Sean Schofield <[EMAIL PROTECTED]> wrote: > > 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?
That's correct ... presumably if one had a styleId attribute on the component that dictated what the emitted "id" value would be, both the encode and decode methods could share that understanding. > > > 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. Feasibility isn't really my concern ... but it becomes less and less clear why a scheme like this would be better than what we already have. Well-written JavaScript methods (independent of what technology you use to build your dynamic applications) should be accepting either object references (in which case it can ask the element "hey element, what's your id?") or accepting id values directly as arguments. If you hard code the ids, page authors can break your code even in a pure-HTML-page world, by accidentally or purposefully changing the "id" attributes themselves. The key is to make sure that your renderers create calls to the right Javascirpt methods, with the right id values. Calculating what those id values should be depends on knowing the algorithm being used -- and I don't see how knowing that the calculated id will be whatever you say plus a suffix is any less fragile than knowing the algorithm that the standard JSF components use to calculate the values is. Tell me again why we would care so much, especially in the case of nested repeating components? Craig > > > Craig > > sean >
