Re: [Trinidad] js error on PPR after client-side validation error

[Renzo Tomaselli]

Matthias, here's a page chunk: <tr:panelGroupLayout partialTriggers="add remove update">     <tr:panelHorizontalLayout id="prop" partialTriggers="ptype">         <tr:selectOneChoice id="ptype" value="#{bean.prop.type}" simple="true" autoSubmit="true">             <f:selectItems value="#{bean.propTypes}"/>         </tr:selectOneChoice>         <tr:inputText id="intValue" simple="true" value="#{bean.prop.integerValue}" rendered="#{bean.prop.integerType}"/>         <tr:selectBooleanCheckbox id="boolValue" simple="true" value="#{bean.prop.booleanValue}" rendered="#{bean.prop.booleanType}"/>         <tr:commandButton id="update" text="#{msg['doc.update']}" action="" partialSubmit="true"/> ... Here selecting a type by "ptype" refreshes the panel, thus rendering a different input field. But in the meantime I discovered that if I use distinct ids for involved input fields - then the problem disappears. In this example, if  "intValue" and "boolValue" would be the same string, we would get the reported problem. This shouldn't be necessary since they are mutually exclusive, but it seems that the involved js retains a validator id no matter if the underlying data type was changed by a PPR. -- Renzo Matthias Wessendorf wrote: Can you post a simple page-code sniplet for that ? -M On 11/2/07, Renzo Tomaselli <[EMAIL PROTECTED]> wrote: Hi, while using Trinidad v. 1.0.3, I forced a client-side validation error by entering an invalid short number. At the next PPR, I got a js error on Firebug: "e.getFacesMessage() is not a function" at line 6199 in Common1_0_3.js (in function _multiValidate). The involved line appears to be in a catch such as: catch (e) { converterError = true; // Populate the failureMap with the current error inputFailures[inputFailures.length] = e.getFacesMessage(); } where "e" contains "a0.indexOf is not a function". -- Renzo