myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias Wessendorf" <mat...@apache.org>
Subject Re: [Trinidad] js error on PPR after client-side validation error
Date Tue, 15 Jan 2008 04:23:19 GMT
Renzo,

do you still see this ?

-M

On Nov 5, 2007 12:23 AM, Renzo Tomaselli <renzo.tomaselli@tecnotp.it> wrote:
>
>  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="#{bean.update}" 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 <renzo.tomaselli@tecnotp.it> 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
>
>
>
>
>
>



-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Mime
View raw message