I will create the bug and attach the example code. Thanks for all your help.

If anyone can think of a short term workaround, maybe even a javascript hack
I can fit in myself, that would be great too :-)

-- Paul

On 3/29/06, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
> >From: Laurie Harper <[EMAIL PROTECTED]>
> >
> > Why would that be needed? The s:commonsValidator tag should render
> > Javascript referencing the actual rendered ID of the component it's
> > attached to. I haven't played much with validators, much less validators
> > for components inside dataLists, but I would have thought this should be
> > able to work as it is.
> >
>
> I think this one is a bug.  The dataList component is a naming container
> so any components contained in it, should get a clientId prefix from all
> naming containers that it's nested in.  The dataList extends the UIData
> component who creates it's client id from the current row.
>
> public String getClientId(FacesContext context)
> {
>   String clientId = super.getClientId(context);
>   int rowIndex = getRowIndex();
>   if (rowIndex == -1)
>   {
>    return clientId;
>   }
>   else
>   {
>    return clientId + "_" + rowIndex;
>   }
> }
>
> The validator script collector asks the components with the commons
> validator for their client id after the dataList has done it's renderering
> which renderers it's own children.
>
> I want to say that JSF 1.2 adds a callback to handle this but I don't
> understand the details yet.
>
> Paul, please create a bugzilla ticket on this one.
>
> Gary
>
> > Paul, could you include your sample JSP and, if possible, copy/paste the
> > rendered HTML as well, in a Bugzilla ticket so the issue gets tracked?
> >
> > L.
> >
> > Hermod Opstvedt wrote:
> > > Hi
> > >
> > > Did I hear forceId? - You need to use this attribute to force the name
> to be
> > > what you want.
> > >
> > > Hermod
> > >
> > >
> > > -----Opprinnelig melding-----
> > > Fra: Paul Devine [mailto:[EMAIL PROTECTED]
> > > Sendt: 29. mars 2006 22:47
> > > Til: user@struts.apache.org
> > > Emne: [Shale] commons client side validation not working inside a
> dataList
> > >
> > > I tried using the commons validation features of Shale. The
> application is
> > > using Myfaces 1.1.1. The validation javascript is being written back
> to the
> > > browser. The server side validation is working fine but a javascript
> `field
> > > error occurs during the . However there is a problem with the client
> side
> > > input element Id's that the javascript validation is looking for
> versus the
> > > client side id's that are generated by the dataList. The page i tried
> > > validation on has a Myfaces dataList inside a form, and for each
> iteration
> > > through the list there are inputs. Basically a dataList will append
> the `row
> > > index` to the client side Id to guarantee uniqueness, as in
> > > "myForm:myDataList_0:someRequiredField" for the first row,
> > > "myForm:myDataList_1:someRequiredField" for the second, and so on. But
> in
> > > the rendering of the javascript by the struts validatorScript tag, the
> > > clientId of the input components lose their row index.
> > >
> > > I have created an illustrative example that generates the same
> problem. The
> > > code is included below and the inline comments hopefully explain
> what's
> > > happening. To keep things simple there is no backing bean, and I use a
> > > class from shale-core to give me some objects to edit, so all you'd
> just
> > > need to deploy into a shale-core based "blank" web-app. My application
> page
> > > is more complex than this but I am running into exact the same problem
> > > withthe validation javascript
> > >
> > > Does this look familiar to anyone? Any workarounds, solutions?...
> > >
> > > Thanks
> > > -- Paul Devine
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > > > rowIndexVar="index">
> > >
> > >
> > > > > required="true">
> > > > > client="true"/>
> > > > > errorClass="errorMessage"/>
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>

Reply via email to