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. > > Do you want the id attribute set so that javascript associated with > AJAX-type controls can find this viewstate field? > 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 > >
