Details

      Description

      in following code fragement the action-method "testService.listenOnSelect" is never called:

      <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
      <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
      <%@ taglib uri="http://myfaces.apache.org/tomahawk" prefix="t"%>
      <f:subview id="test">
      <h:form id="testform">
      <h:panelGrid columns="1">
      <t:dataList id="datalist" style="standardList"
      var="test"
      value="#

      {testService.entries}

      "
      rowCountVar="rowCount"
      rowIndexVar="rowIndex"
      layout="unorderedList">
      <h:commandLink id="test_ref" value="#

      {rowIndex + 1}" action="#{testService.listenOnSelect}" />
      </t:dataList>
      </h:panelGrid>
      </h:form>
      </f:subview>

      after some testing i also tried the nightly build but with the same result

      also tried the following (working in other scenarios):
      <h:commandLink id="testref" immediate="true" value="#{rowIndex + 1}

      " action="">
      <t:updateActionListener property="#

      {rowCount}

      " value="#

      {testService.searchRow}

      " />
      </h:commandLink>

      any ideas?

      1. api.txt
        1 kB
        Dennis Byrne
      2. tomahawk.txt
        3 kB
        Dennis Byrne
      3. tomahawk2.txt
        4 kB
        Dennis Byrne

        Issue Links

          Activity

          Hide
          Dennis Byrne added a comment -

          Yes, they are seperate and MYFACES-1009 is still present . Not sure why this one was cloned.

          Show
          Dennis Byrne added a comment - Yes, they are seperate and MYFACES-1009 is still present . Not sure why this one was cloned.
          Hide
          Martin Marinschek added a comment -

          Should we open 1009 again then?

          regards,

          Martin

          Show
          Martin Marinschek added a comment - Should we open 1009 again then? regards, Martin
          Hide
          Dennis Byrne added a comment -

          Yeah, this one is fixed. I have reproduced the 1009 behavior w/out the RI. Didn't try to fix it. It looked like 853 and 1009 were the same problem, same component, different lifecycle phase. I'm pretty sure datalist does not currently call processUpdates or processValidations on it's children.

          Show
          Dennis Byrne added a comment - Yeah, this one is fixed. I have reproduced the 1009 behavior w/out the RI. Didn't try to fix it. It looked like 853 and 1009 were the same problem, same component, different lifecycle phase. I'm pretty sure datalist does not currently call processUpdates or processValidations on it's children.
          Hide
          Martin Marinschek added a comment -

          I wonder why I reopened that?

          If there was a mail; I should have appended it right away...

          Is that fixed - what do you say, Dennis, you prepared the fix? You know about MYFACES-1009, too, right? I suppose the reason for MYFACES-1009 might have been using the RI as well...

          I think we can call this fixed, it would of course not work with the RI though, due to MYFACES-1010.

          regards,

          Martin

          Show
          Martin Marinschek added a comment - I wonder why I reopened that? If there was a mail; I should have appended it right away... Is that fixed - what do you say, Dennis, you prepared the fix? You know about MYFACES-1009 , too, right? I suppose the reason for MYFACES-1009 might have been using the RI as well... I think we can call this fixed, it would of course not work with the RI though, due to MYFACES-1010 . regards, Martin
          Hide
          Dave added a comment -

          dataList can be thought as dataTable with one column. It might be better to add an abstraction layer. Just a thought.

          Show
          Dave added a comment - dataList can be thought as dataTable with one column. It might be better to add an abstraction layer. Just a thought.
          Hide
          Dennis Byrne added a comment -

          dataList inherits (from the dataTable component) the methods used to update the model. however these methods are looking for column components, which are not found under dataList.

          Show
          Dennis Byrne added a comment - dataList inherits (from the dataTable component) the methods used to update the model. however these methods are looking for column components, which are not found under dataList.
          Hide
          Dave added a comment -

          Is there any logical difference between dataList and dataTable? The only difference is the rendering to HTML, right? dataTable is working well.

          Show
          Dave added a comment - Is there any logical difference between dataList and dataTable? The only difference is the rendering to HTML, right? dataTable is working well.
          Hide
          Dennis Byrne added a comment -

          Martin,

          There is another one on dataList for update model http://issues.apache.org/jira/browse/MYFACES-1009 .

          Show
          Dennis Byrne added a comment - Martin, There is another one on dataList for update model http://issues.apache.org/jira/browse/MYFACES-1009 .
          Hide
          Dave added a comment -

          I tested the latest build today for dataList.

          <commandLink> works.
          but <inputText> did not work. the setter method (setTitle) was never called during model update.

          -------------TestBean.java --------------

          import java.util.ArrayList;
          import java.util.List;

          public class TestBean {
          private String name;
          private List<Book> books;

          public TestBean() {
          books = new ArrayList<Book>();
          for (int i=0; i<10; i++)

          { books.add(new Book("Title" + i, "Author" + i)); }

          }
          public List<Book> getBooks()

          { return books; }

          public void setBooks(List<Book> books)

          { this.books = books; }

          public String getName()

          { return name; }

          public void setName(String name)

          { this.name = name; }

          public String clickLink()

          { System.out.println("Clicked" ); return null; }

          }

          -----------------Book.java -----------------

          public class Book {
          private String title;
          private String author;

          public Book() {

          }
          public Book(String title, String author)

          { this.title = title; this.author = author; }

          public String getAuthor()

          { return author; }

          public void setAuthor(String author)

          { this.author = author; }

          public String getTitle()

          { return title; }

          public void setTitle(String title)

          { this.title = title; }

          public String clickLink()

          { System.out.println("Click: " + getTitle()); return null; }

          }

          ---------------------test.jsp --------------------------

          <%@ page contentType="text/html; charset=UTF-8"%>
          <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
          <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
          <%@ taglib uri="http://myfaces.apache.org/tomahawk" prefix="t"%>
          <HTML>
          <head>
          </head>
          <f:view>
          <%-- test dataList --%>
          <h:form>
          <t:dataList id="books"
          var="book"
          value="#

          {testBean.books}

          "
          layout="simple"
          rowCountVar="rowCount"
          rowIndexVar="rowIndex">

          <h:commandLink value="#

          {book.title}"
          action="#{book.clickLink}"/>

          <f:verbatim> </f:verbatim>

          <h:inputText value="#{book.title}

          "/>

          <f:verbatim> </f:verbatim>

          </t:dataList>

          <h:commandButton value="Submit" />
          </h:form>
          </f:view>
          </HTML>

          Show
          Dave added a comment - I tested the latest build today for dataList. <commandLink> works. but <inputText> did not work. the setter method (setTitle) was never called during model update. -------------TestBean.java -------------- import java.util.ArrayList; import java.util.List; public class TestBean { private String name; private List<Book> books; public TestBean() { books = new ArrayList<Book>(); for (int i=0; i<10; i++) { books.add(new Book("Title" + i, "Author" + i)); } } public List<Book> getBooks() { return books; } public void setBooks(List<Book> books) { this.books = books; } public String getName() { return name; } public void setName(String name) { this.name = name; } public String clickLink() { System.out.println("Clicked" ); return null; } } -----------------Book.java ----------------- public class Book { private String title; private String author; public Book() { } public Book(String title, String author) { this.title = title; this.author = author; } public String getAuthor() { return author; } public void setAuthor(String author) { this.author = author; } public String getTitle() { return title; } public void setTitle(String title) { this.title = title; } public String clickLink() { System.out.println("Click: " + getTitle()); return null; } } ---------------------test.jsp -------------------------- <%@ page contentType="text/html; charset=UTF-8"%> <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%> <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%> <%@ taglib uri="http://myfaces.apache.org/tomahawk" prefix="t"%> <HTML> <head> </head> <f:view> <%-- test dataList --%> <h:form> <t:dataList id="books" var="book" value="# {testBean.books} " layout="simple" rowCountVar="rowCount" rowIndexVar="rowIndex"> <h:commandLink value="# {book.title}" action="#{book.clickLink}"/> <f:verbatim> </f:verbatim> <h:inputText value="#{book.title} "/> <f:verbatim> </f:verbatim> </t:dataList> <h:commandButton value="Submit" /> </h:form> </f:view> </HTML>
          Hide
          Martin Marinschek added a comment -

          patch by Dennis Byrne. Thanks a lot!

          Show
          Martin Marinschek added a comment - patch by Dennis Byrne. Thanks a lot!
          Hide
          Martin Marinschek added a comment -

          Thanks Dennis, as far as I can see, perfect now!

          Muchos gracias,

          regards,

          Martin

          Show
          Martin Marinschek added a comment - Thanks Dennis, as far as I can see, perfect now! Muchos gracias, regards, Martin
          Hide
          Dennis Byrne added a comment -

          ... OK guys Anyone else want to take a shot?

          Show
          Dennis Byrne added a comment - ... OK guys Anyone else want to take a shot?
          Hide
          Simon Kitching added a comment -

          Dennis: note that it's also forbidden to add any public class or interface to the javax.faces packages.
          The existing utility classes in the API module are only package-scope, ie are not accessable from
          anywhere except the same package.

          Of course this problem does not occur for the Impl module, where utility classes are fine. However
          api classes can't depend on anything in impl or commons.

          Show
          Simon Kitching added a comment - Dennis: note that it's also forbidden to add any public class or interface to the javax.faces packages. The existing utility classes in the API module are only package-scope, ie are not accessable from anywhere except the same package. Of course this problem does not occur for the Impl module, where utility classes are fine. However api classes can't depend on anything in impl or commons.
          Hide
          Martin Marinschek added a comment -

          Thanks Dennis. We'll commit when this is fixed.

          You'll need to replicate - you'll always have to think about users not using MyFaces and still using dataList - they won't gain anything if you change the process method to use a static-util function in the API, cause they don't have the MyFaces API implementation in their classpath. So duplicate code is our only option here, as much as I hate to copy code myself. Best would be to document the duplication, though, so if someone changes one implementation of the function, he knows that he needs to change the other one as well.

          Please, also take care to send in the patch according to the MyFaces code-style (e.g. { in new lines).

          regards,

          Martin

          Show
          Martin Marinschek added a comment - Thanks Dennis. We'll commit when this is fixed. You'll need to replicate - you'll always have to think about users not using MyFaces and still using dataList - they won't gain anything if you change the process method to use a static-util function in the API, cause they don't have the MyFaces API implementation in their classpath. So duplicate code is our only option here, as much as I hate to copy code myself. Best would be to document the duplication, though, so if someone changes one implementation of the function, he knows that he needs to change the other one as well. Please, also take care to send in the patch according to the MyFaces code-style (e.g. { in new lines). regards, Martin
          Hide
          Dennis Byrne added a comment -

          Ouch ... my mistake. Are you comfortable moving process() to a static method in one of util classes of the api packages?
          There are already at least three copies of process() in the codebase and I didn't want to put another in HtmlDataList.

          Shale unit test discussion will come in a week or so. MyFaces and Shale/unit test framework don't play too nice together sometimes

          Show
          Dennis Byrne added a comment - Ouch ... my mistake. Are you comfortable moving process() to a static method in one of util classes of the api packages? There are already at least three copies of process() in the codebase and I didn't want to put another in HtmlDataList. Shale unit test discussion will come in a week or so. MyFaces and Shale/unit test framework don't play too nice together sometimes
          Hide
          Bruno Aranda added a comment -

          Dennis, about the test framework can you make a proposal in the dev mailing list? Thanks!

          Show
          Bruno Aranda added a comment - Dennis, about the test framework can you make a proposal in the dev mailing list? Thanks!
          Hide
          Bruno Aranda added a comment -

          Thanks Dennis, but I am afraid that this patch is not ok. We cannot change the visibility of API methods as they are defined by the spec. Otherwise myfaces would not be compatible with the RI. Maybe you could make a patch without modifying UIData (or at least without changing the visibility of its methods)?

          Show
          Bruno Aranda added a comment - Thanks Dennis, but I am afraid that this patch is not ok. We cannot change the visibility of API methods as they are defined by the spec. Otherwise myfaces would not be compatible with the RI. Maybe you could make a patch without modifying UIData (or at least without changing the visibility of its methods)?
          Hide
          Dennis Byrne added a comment -

          This works for commandLinks and commandButtons. Martin, you were correct - fixing the first problem solved the second one as well.

          Show
          Dennis Byrne added a comment - This works for commandLinks and commandButtons. Martin, you were correct - fixing the first problem solved the second one as well.
          Hide
          Dennis Byrne added a comment -

          Hello Martin,

          I have approached it from a couple of different angles and it always seems to break something else though. I'm playing aroung with Shale's test framework ... http://struts.apache.org/struts-shale/features-test-framework.html . Maybe I can convince MyFaces to add yet another jar file to SVN .

          Show
          Dennis Byrne added a comment - Hello Martin, I have approached it from a couple of different angles and it always seems to break something else though. I'm playing aroung with Shale's test framework ... http://struts.apache.org/struts-shale/features-test-framework.html . Maybe I can convince MyFaces to add yet another jar file to SVN .
          Hide
          Martin Marinschek added a comment -

          Dennis,

          you're absolutely right with your evaluation of the first problem. This should be fixed asap... Hope we'll find someone to do the actual work

          I believe that the second problem corresponds to the first one, though (without spending too much time on deeper reflection). As the iteration doesn't happen, the client-id isn't properly synch'ed, either. So maybe by fixing #1, you'll also fix #2!

          regards,

          Martin

          Show
          Martin Marinschek added a comment - Dennis, you're absolutely right with your evaluation of the first problem. This should be fixed asap... Hope we'll find someone to do the actual work I believe that the second problem corresponds to the first one, though (without spending too much time on deeper reflection). As the iteration doesn't happen, the client-id isn't properly synch'ed, either. So maybe by fixing #1, you'll also fix #2! regards, Martin
          Hide
          Mike Kienenberger added a comment -

          Duplicate of MYFACES-853

          Show
          Mike Kienenberger added a comment - Duplicate of MYFACES-853
          Hide
          Dennis Byrne added a comment -

          This is the same thing over in http://issues.apache.org/jira/browse/MYFACES-954 .

          The children of dataList are not decoded, and any browser event (at least, for commandLinks), cannot be registered even if children were decoded

          HtmlDataList inherits processDecodes from UIData. UIData.processDecodes calls methods like processFacets(), processColumnFacets() and processColumnChildren() . All three of these methods fail to decode children such as plain commandLinks and commandButtons (which are often found below t:dataList w/out facets and columns). Consequently, command children of dataList elements are not properly decoded during the apply request values phase. Events for these commands are of course not registered, which is why neither action listeners nor actions are invoked in later phases.

          This can be fixed by making HtmlDataList implment it's own processDecodes() w/ a simple call to getChildren() and for loop. Decoding would be delegated to the Renderer for each child. Normally, HtmlLinkRendererBase does this, and it queus an event whenever the clientId matches the value of the HTTP parameter link_hidden . This event would result in a method firing during the invoke application phase, provided the action source is not immediate. However this does not happen because the UIComponent, in this case an action source, does not give the proper clientId to the renderer. In other words, the link_hidden HTTP request parameter does not match the value returned by HtmlCommandLink.getClientId() . For example, say we have the following in a JSP ...

          <t:dataList id="dataList" var="item" value="#

          {UserLister.dataModel.wrappedData}

          " >
          <h:commandLink value="#

          {item}

          " action="#

          {UserCrud.retrieve}

          " >
          <t:updateActionListener property="#

          {UserCrud.id}

          " value="#

          {item.myUserId}

          " />
          </h:commandLink>
          </t:dataList>

          After clicking in the first link, the resulting HTTP parameter value for link_hidden ends up being dataList_0:_idJsp3. This is correct, but the link renderer is looking for dataList:_idJsp3 ( see HtmlLinkRendererBase.decode() ). This means HtmlDataList.getClientId() ( I am not in favor of changing clientId implementation for action sources) may also have to be changed.

          I have not stepped through this w/ commandButton.

          Can anyone point me to info on HtmlDataTableHack ?

          Show
          Dennis Byrne added a comment - This is the same thing over in http://issues.apache.org/jira/browse/MYFACES-954 . The children of dataList are not decoded, and any browser event (at least, for commandLinks), cannot be registered even if children were decoded HtmlDataList inherits processDecodes from UIData. UIData.processDecodes calls methods like processFacets(), processColumnFacets() and processColumnChildren() . All three of these methods fail to decode children such as plain commandLinks and commandButtons (which are often found below t:dataList w/out facets and columns). Consequently, command children of dataList elements are not properly decoded during the apply request values phase. Events for these commands are of course not registered, which is why neither action listeners nor actions are invoked in later phases. This can be fixed by making HtmlDataList implment it's own processDecodes() w/ a simple call to getChildren() and for loop. Decoding would be delegated to the Renderer for each child. Normally, HtmlLinkRendererBase does this, and it queus an event whenever the clientId matches the value of the HTTP parameter link_hidden . This event would result in a method firing during the invoke application phase, provided the action source is not immediate. However this does not happen because the UIComponent, in this case an action source, does not give the proper clientId to the renderer. In other words, the link_hidden HTTP request parameter does not match the value returned by HtmlCommandLink.getClientId() . For example, say we have the following in a JSP ... <t:dataList id="dataList" var="item" value="# {UserLister.dataModel.wrappedData} " > <h:commandLink value="# {item} " action="# {UserCrud.retrieve} " > <t:updateActionListener property="# {UserCrud.id} " value="# {item.myUserId} " /> </h:commandLink> </t:dataList> After clicking in the first link, the resulting HTTP parameter value for link_hidden ends up being dataList_0:_idJsp3. This is correct, but the link renderer is looking for dataList:_idJsp3 ( see HtmlLinkRendererBase.decode() ). This means HtmlDataList.getClientId() ( I am not in favor of changing clientId implementation for action sources) may also have to be changed. I have not stepped through this w/ commandButton. Can anyone point me to info on HtmlDataTableHack ?
          Hide
          Jesper Pedersen added a comment -

          Its on testServices <t:saveState value="#

          {testServices}

          "/>

          Hope this helps.

          Show
          Jesper Pedersen added a comment - Its on testServices <t:saveState value="# {testServices} "/> Hope this helps.
          Hide
          Mike Kienenberger added a comment -

          It'd help if you'd post your t:saveState tag.

          Hopefully, you're using it on testService.entries or testService. You cannot use it on test.

          -Mike

          Show
          Mike Kienenberger added a comment - It'd help if you'd post your t:saveState tag. Hopefully, you're using it on testService.entries or testService. You cannot use it on test. -Mike
          Hide
          Jesper Pedersen added a comment -

          I'm using SVN HEAD currently - the MyFaces-1.1.1 release worked ok with the <t:saveState> tag.

          Best regards,
          Jesper

          Show
          Jesper Pedersen added a comment - I'm using SVN HEAD currently - the MyFaces-1.1.1 release worked ok with the <t:saveState> tag. Best regards, Jesper
          Hide
          Martin Marinschek added a comment -

          I wonder if you are using the Reference Implementation with the tomahawk-jar?

          regards,

          Martin

          Show
          Martin Marinschek added a comment - I wonder if you are using the Reference Implementation with the tomahawk-jar? regards, Martin
          Hide
          Jesper Pedersen added a comment -

          Any known workarounds ?

          I'm using a <t:saveState> tag inside the <h:form>, but that doesn't either.

          Show
          Jesper Pedersen added a comment - Any known workarounds ? I'm using a <t:saveState> tag inside the <h:form>, but that doesn't either.

            People

            • Assignee:
              Dennis Byrne
              Reporter:
              Alexander Traeder
            • Votes:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development