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] ? > > Yes. The problem is when you use s:inputSuggestAjax and s:tableSuggestAjax > with trinidad. This components send a request for load the suggestions and > show it. If the id is not present, the viewstate is not found, so it is not > sent in the request (and not available on the request map), the state is not > restored and finally breaks tomahawk ajax api (and many dojo components!). > >> >> Regards, Simon >> > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
