The RI doesn't it just uses the private accessor "rowIndex" - and not
getRowIndex(). See below. I think Mathias is absolutely right in that
this whole problem boils down to the fact that it shouldn't.

Plus, I'm moving this over to the jira-issue, so that we can keep
track of the issue there.

http://issues.apache.org/jira/browse/MYFACES-1010?page=comments#action_12362262

    public String getClientId(FacesContext context) {

        if (context == null) {
            throw new NullPointerException();
        }
        String baseClientId = super.getClientId(context);
        if (rowIndex >= 0) {
            return (baseClientId + NamingContainer.SEPARATOR_CHAR + rowIndex);
        } else {
            return (baseClientId);
        }

    }

regards,

Martin

On 1/10/06, Adam Winer <[EMAIL PROTECTED]> wrote:
> As Claudio noted above, the RI does call getRowIndex() in 
> UIData.getClientId().
>
> Generally speaking, it's very important to call setRowIndex() during 
> iteration,
> for getting the state of the subcomponents in sync, for getting client IDs
> correct, and for establishing the "var" of the table correctly when calling
> through to event listeners on children.
>
> -- Adam
>
>
> On 1/9/06, Mathias Broekelmann (JIRA) <[email protected]> wrote:
> >     [ 
> > http://issues.apache.org/jira/browse/MYFACES-1010?page=comments#action_12362262
> >  ]
> >
> > Mathias Broekelmann commented on MYFACES-1010:
> > ----------------------------------------------
> >
> > I took a closer look into the sources. I now think that we should not call 
> > super.setRowIndex(..) at all.
> > The problem is that this method implements the most tricky part of the 
> > UIData class. It stores and restores the state of the nested components to 
> > iterate through the rows. If we do it we would at least get the state 
> > saving/restoring done 3 times (HtmlDataTableHack will do this a 3rd. time). 
> > I will not say that this is not possible to do. It´s probably more a 
> > problem where we should call the super method in setRowIndex. But after all 
> > it´s still a workaround.
> >
> > The best solution would be to change the code in RI. Why do they not call 
> > getRowIndex() in getClientId()?
> >
> > > Extended Data Table: Action Event delivered more than one time
> > > --------------------------------------------------------------
> > >
> > >          Key: MYFACES-1010
> > >          URL: http://issues.apache.org/jira/browse/MYFACES-1010
> > >      Project: MyFaces
> > >         Type: Bug
> > >   Components: Tomahawk (RI Compatability)
> > >     Versions: 1.1.1
> > >  Environment: Apache Tomcat 5.5.12 or OC4j 10.1.3 DP4, Win Xp, Sun  RI 
> > > 1.1.01 , JDK 1.5
> > >     Reporter: Claudio Tasso
> >
> > >
> > > Hi,
> > > I'm trying using Tomahawk t:dataTable and it seems to me that its 
> > > behaviour is very different from the standard  JSF h:dataTable.
> > > Consider a column which contains a command button and a table with two 
> > > rows. When the user clicks on the button of the first row, two action 
> > > events are generated!
> > > For example, look at this very simple code:
> > > <f:view>
> > >    <h:form>
> > >        <h:dataTable value="#{testBean.persons}" var="item" 
> > > binding="#{testBean.uiData}">
> > >            <h:column>
> > >                <h:commandButton value="Test" 
> > > action="#{testBean.test}"></h:commandButton>
> > >            </h:column>
> > >            <h:column>
> > >                <h:outputText value="#{item.name}"></h:outputText>
> > >            </h:column>
> > >            <h:column>
> > >                <h:outputText value="#{item.surname}"></h:outputText>
> > >            </h:column>
> > >        </h:dataTable>
> > >              <t:dataTable value="#{testBean.persons}" var="item" 
> > > binding="#{testBean.htmlDataTable}" preserveDataModel="false">
> > >            <t:column>
> > >                <h:commandButton value="Test" 
> > > action="#{testBean.test2}"></h:commandButton>
> > >            </t:column>
> > >            <t:column>
> > >                <h:outputText value="#{item.name}"></h:outputText>
> > >            </t:column>
> > >            <t:column>
> > >                <h:outputText value="#{item.surname}"></h:outputText>
> > >            </t:column>
> > >        </t:dataTable>
> > >    </h:form>
> > > </f:view>
> > > When the user clicks the "Test" button of the h:dataTable, the 
> > > "testBean.test" method is executed just one time.
> > > But when the user clicks the "Test" button of the t:dataTable the 
> > > "testBean.test2" method is executed twice ( or three times if the table 
> > > has 3 rows, and so on...).
> > > I suppose  that the problem is that the elements of  t:dataTable which 
> > > belongs to differnt rows have the same ID, and during the processDecode 
> > > phase the same event is broadcasted more than one time.
> > > In fact, this is the html code which is generated by Tomahawk extended 
> > > datatable:
> > > <table>
> > > <tbody id="_id0:_id8:tbody_element">
> > > <tr>
> > > <td><input type="submit" name="_id0:_id8:_id10" value="Test" /></td>
> > > <td>John</td>
> > > <td>Smith</td>
> > > </tr>
> > > <tr><td><input type="submit" name="_id0:_id8:_id10" value="Test" /></td>
> > > <td>Mark</td>
> > > <td>Greene</td>
> > > </tr></tbody>
> > > </table>
> > > and this is the html code which is generated by RI h:dataTable:
> > > <table>
> > > <tbody>
> > > <tr>
> > > <td><input type="submit" name="_id0:_id1:0:_id3" value="Test" /></td>
> > > <td>John</td>
> > > <td>Smith</td>
> > > </tr>
> > > <tr>
> > > <td><input type="submit" name="_id0:_id1:1:_id3" value="Test" /></td>
> > > <td>Mark</td>
> > > <td>Greene</td>
> > > </tr>
> > > </tbody>
> > > </table>
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > If you think it was sent incorrectly contact one of the administrators:
> >    http://issues.apache.org/jira/secure/Administrators.jspa
> > -
> > For more information on JIRA, see:
> >    http://www.atlassian.com/software/jira
> >
> >
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Reply via email to