> If you're hard coding them today, what stops you (like you, ignoring > the repeating case) from hard coding the JSF-generated values? They > are perfectly predictable if you use "id" elements on the form and the > input field itself.
While its true that these elements are predictable, I think there are some problems with this approach. The first issue goes to ease of use. This requires that I change all of my javascript (and there is a ton of it.) Not the end of the world but I'd rather "take one for the team" and implement a fix in an implmentation so others do not have to deal with this. The developers on my team strongly urged me to hold off on faces for now just based on this single issue. If the goal is to have faces catch on with the development community, we should make it as easy as possible. The second issue is that now my javascript is tied to JSF. If I ever stop using faces (or the faces spec/implementation changes on me), then I'm back to changing all of my javascript again. (Maybe I am missing something here, but that seems to be the implication.) The third issue is that even though its predictable its not allways very easy to determine. In my case I'm using lots of tiles (subviews). I seem to recall that the id's of these attributes is affected by whether or not they are in subviews. So its difficult to determine ahead of time and will be incorrect if I change the way I'm laying things out. Finally, there is the more complicated "nested" case. If my wizard is generating multiple values (say picking 0-n names from an address book wizard) then things get really complicated. The HTML being submitted on the form doesn't even exist yet. Its generated dynamically from the javascript (so you're submitting a contact[0], contact[1], etc. I'm not even sure how I would manage this if id's were not an issue, but that's for another day. > Craig sean
