4 Replies Latest reply on Aug 13, 2007 11:29 AM by Pete Muir

    Trinidad table binding

    Marco Pancotti Newbie

      I'm writing an application using a mix of Trinidad and RichFaces controls. I used the SeamDisc example in CVS for the setup and it's working.

      I'm using a tr:table with the following header:

      <tr:table id="partyTypeList" value="#{partyTypes.dataModel}"
       var="partyType" rowBandingInterval="1" rows="10"
       rowSelection="multiple" binding="#{partyTypesManager.table}">


      The binding does not work, I get a
      javax.el.ELException: /party/partyTypes.xhtml @31,68 binding="#{partyTypesManager.table}": java.lang.IllegalArgumentException: argument type mismatch
      .

      As you can imagine I carefully used the example in the TRinidad web site and double.checked the code of the bean, that is:

      @Name("partyTypesManager")
      @Scope(ScopeType.SESSION)
      public class PartyTypesManager {
      
       public void performDelete(ActionEvent action){
       UIXTable table = getTable();
       Iterator selection = table.getSelectedRowKeys().iterator();
       Object oldKey = table.getRowKey();
       while(selection.hasNext()){
       Object rowKey = selection.next();
       table.setRowKey(rowKey);
       PartyType pt = (PartyType) table.getRowData();
       System.out.println("PartyType "+pt.getId()+" marked for deletion");
       }
       table.setRowKey(oldKey);
       }
      
       private UIXTable _table;
       public UIXTable getTable() {
       return _table;
       }
       public void setTable(UIXTable table) {
       this._table = table;
       }
      
      }



      I red an old post that said to not try to use a binding of a trinidad table in Seam. Is it still true? The SeamDisc example did not bind any table to a backing bean, so i do not have any hint.

      The binding is necessary to use the multirow selection feature, one of the many differences between the Trinidad table and the RichFaces table.

      Thanks
      Marco

        • 1. Re: Trinidad table binding
          Pete Muir Master

          I would avoid binding where possible. In this case you can use the selectionListener or selectedRowKeys attributes I think instead.

          • 2. Re: Trinidad table binding
            Marco Pancotti Newbie

            Thanks for the answer.

            I'll avoid the binding, as you suggest, but it is not without a loss of elegance in the code.

            If you select many rows and use a listener you do a roundtrip for every selection (to save the keys of the selected rows somewhere) , while you actually need only the last one, when you activate the command (in instance, when you click the "delete" button after having selected the delatable rows).

            But the real question is:

            Is this problem in the binding of the trinidad table something concerning this specific components or is it something that affects other components and/or the whole seam/trinidad cohabitation? The binding problem would affect even a standard h:dataTable or the rich:dataTable components (even if you do not need to bind a standard datatable as you do not have any information to collect)?

            Thanks a lot

            Marco

            • 3. Re: Trinidad table binding
              Stuart Robertson Novice

              I'm curious about this as well. I understand that binding JSF components to logic in Seam component is somewhat impure. But occassionally it's needed.

              Pete, do you suggest avoiding binding because it won't work with Seam or because it isn't as elegant?

              • 4. Re: Trinidad table binding
                Pete Muir Master

                Because it isn't elegant. You can do it (but you must bind to an EVENT scoped component, or SESSION I guess, just not conversational). N.B. You can also inject the JSF component using

                @In("#{uiComponent['clientId']}") UIComponent cmp;


                which I think is much neater (and doesn't have scope restrictions).

                I haven't used this pattern much, so can't offer best practice advice atm.