Matthias Wessendorf schrieb: > On Thu, Jun 12, 2008 at 7:02 AM, Leonardo Uribe <[EMAIL PROTECTED]> wrote: > >> On Thu, Jun 12, 2008 at 8:51 AM, [EMAIL PROTECTED] >> <[EMAIL PROTECTED]> wrote: >> >>> Leonardo Uribe schrieb: >>> >>>> >>>> On Wed, Jun 11, 2008 at 11:24 PM, Matthias Wessendorf >>>> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: >>>> >>>> > I want to know if any developer has a reason to avoid render >>>> this id, and if >>>> > no objections I'll commit this change in 72 hours (doing this >>>> > s:inputSuggestAjax and s:tableSuggestAjax could work with >>>> trinidad and/or >>>> > facelets and solve TOMAHAWK-1157). >>>> >>>> so, I guess I am not 100% getting your mail. >>>> why is the id needed ? >>>> >>>> >>>> For detect when a request is a postback using the procedure on the >>>> documentation. If is a postback the state is restored an the full >>>> lifecycle occur. If not a new view is created. >>>> >>>> Who detects postback in this way? the jsf implementation used! >>>> >>> I think Matthias meant that the html "name" attribute is all that is >>> significant for html. That is what gets used in creating the http post >>> data. The "id" attribute is only relevant for javascript and css. And >>> css certainly shouldn't be accessing this field. >>> > > yup > > >>> Do you want the id attribute set so that javascript associated with >>> AJAX-type controls can find this viewstate field? >>> > > why not getElementsByName[0] ? >
Well, in general document.getElementById is both faster and more elegant. So in this case, rendering this component with id=clientId seems reasonable. Hmm..but it is possible that there are multiple "view state" fields in the page, one per form. So perhaps using "getElementsByName" is a good idea in this specific case. Question: in systems like portals, how does replacing the viewstate work? Presumably we would only want to replace the viewstate for those hidden inputs that really came from the same jsf view? Regards, Simon
