ICEfaces
  1. ICEfaces
  2. ICE-2016

JSF <navigation-rule> mechanism doesn't work for portlets

          Details

          • Type: Improvement Improvement
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 1.6
          • Fix Version/s: 1.7DR#1, 1.7
          • Component/s: None
          • Labels:
            None
          • Environment:
            WinXP / Liferay 4.3.1 / Tomcat 6.0.13

            Description

            This is a similar problem to ICE-1672 but is far worse. Navigation rules aren't firing at all for portlets. Again, I think this is a reprocussion of abandoning the JSF-Portlet bridge.

            Now, the reason why I didn't find this sooner is because I think that for a portlet to be truly "rich", that navigation rules should be avoided at all costs. Isn't the whole point of ICEfaces so that I don't have to reload the page???

            Regardless, there are cases where page navigation will be necessary. And so I would reluctantly say that this is a very serious one.

            -- Neil

            P.S. Drop the attached portlet in your $HOME/liferay/deploy (aka hot-deploy) folder and it will hot-deploy itself when the portal is running. When you click on the button, you're supposed to be able to navigate from View.jsp to ThankYou.jspx

              Activity

              Ascending order - Click to sort in descending order
              Hide
              Permalink
              Deryk Sinotte added a comment -

              I've spent a fair amount of time on this and have characterized the fundamental issues involved.

              1) I have a portlet that test a couple of different kinds of navigations and all mechanisms work in JBoss Portal 2.6.1 GA (with one caveat which I'll get to later). The reason it works may not be the correct solution but you can navigate back and forth using both normal JSF navigation mechanisms. The navigation does NOT work in Liferay 4.3.0 (I haven't tried 4.3.1 yet as it has only become recently available but I'll test it shortly).

              2) The reason why it doesn't work in Liferay (and does in JBoss) is related to how the FormRenderer encodes the id attribute and D2D rendering. When you navigate in a portlet without a redirect set in your JSF navigation rules, ICEfaces attempts to update the the view "in place" using our standard technique of detecting what has changed and only sending the differences. Depending on the scope of the changes, ICEfaces may traverse all the way up to the <body> (looking for a container component) to update, basically swapping out the whole page.

              In JBoss, the form id attributes of the documents being compared are always the same and the difference detection works as expected as it finds only the small bit of text to change. In Liferay, under certain situations, the form id attributes do NOT match and the D2D then attempts to replace the contents of the <body> (the top container). The body does not have an id (ICEfaces expects id="body") and the bridge fails to apply the update. Even if the id is present (e.g. using Firebug to hack the HTML) and the bridge succeeds, this is a complete no-no in a portlet environment as the entire portal page is replaced.

              3) If you give the form(s) and ID, JBoss stops working as well. First, our FormRenderer encoding doesn't seem to apply the portlet namespace. Second, even if it did, the ids between the views would not be guaranteed to match (as they do in the trivial test case) and the D2D mechanism would still try and walk up the DOM until it found a container.

              The next step is to determine the best way to solve the various issues. At this point, I'm thinking that we may need to provide our own reliable portlet container component (or as a work-around, have the developer add something reliable) but more investigation is required.

              Show
              Deryk Sinotte added a comment - I've spent a fair amount of time on this and have characterized the fundamental issues involved. 1) I have a portlet that test a couple of different kinds of navigations and all mechanisms work in JBoss Portal 2.6.1 GA (with one caveat which I'll get to later). The reason it works may not be the correct solution but you can navigate back and forth using both normal JSF navigation mechanisms. The navigation does NOT work in Liferay 4.3.0 (I haven't tried 4.3.1 yet as it has only become recently available but I'll test it shortly). 2) The reason why it doesn't work in Liferay (and does in JBoss) is related to how the FormRenderer encodes the id attribute and D2D rendering. When you navigate in a portlet without a redirect set in your JSF navigation rules, ICEfaces attempts to update the the view "in place" using our standard technique of detecting what has changed and only sending the differences. Depending on the scope of the changes, ICEfaces may traverse all the way up to the <body> (looking for a container component) to update, basically swapping out the whole page. In JBoss, the form id attributes of the documents being compared are always the same and the difference detection works as expected as it finds only the small bit of text to change. In Liferay, under certain situations, the form id attributes do NOT match and the D2D then attempts to replace the contents of the <body> (the top container). The body does not have an id (ICEfaces expects id="body") and the bridge fails to apply the update. Even if the id is present (e.g. using Firebug to hack the HTML) and the bridge succeeds, this is a complete no-no in a portlet environment as the entire portal page is replaced. 3) If you give the form(s) and ID, JBoss stops working as well. First, our FormRenderer encoding doesn't seem to apply the portlet namespace. Second, even if it did, the ids between the views would not be guaranteed to match (as they do in the trivial test case) and the D2D mechanism would still try and walk up the DOM until it found a container. The next step is to determine the best way to solve the various issues. At this point, I'm thinking that we may need to provide our own reliable portlet container component (or as a work-around, have the developer add something reliable) but more investigation is required.
              Hide
              Permalink
              Deryk Sinotte added a comment -

              So we've now added an <ice:portlet> component that should be used by developers to wrap their portlet page fragments. This component is a simple container that extends UINamingContainer so that the D2D rendering can use it as the top level parent for swapping out the entire portlet if necessary rather than climbing all the way up to the body. It also uses the portlet namespace as its clientId so that each portlet is uniquely identified in the page along with it's tree of sub-components. This seems to help immensely with the navigation issues and null ID problems that I was seeing before. I'm going to test a few more things before marking as fixed.

              Show
              Deryk Sinotte added a comment - So we've now added an <ice:portlet> component that should be used by developers to wrap their portlet page fragments. This component is a simple container that extends UINamingContainer so that the D2D rendering can use it as the top level parent for swapping out the entire portlet if necessary rather than climbing all the way up to the body. It also uses the portlet namespace as its clientId so that each portlet is uniquely identified in the page along with it's tree of sub-components. This seems to help immensely with the navigation issues and null ID problems that I was seeing before. I'm going to test a few more things before marking as fixed.
              Hide
              Permalink
              Deryk Sinotte added a comment -

              I've checked out the sample that came attached to the case and it works provided I tweak the contents a bit:

              • update the WEB-INF/lib/icefaces*.jar libraries so that they use the latest built from the head
              • update the .jspx files so that the interesting parts are now surrounded by an <ice:portlet> tag
              Show
              Deryk Sinotte added a comment - I've checked out the sample that came attached to the case and it works provided I tweak the contents a bit: update the WEB-INF/lib/icefaces*.jar libraries so that they use the latest built from the head update the .jspx files so that the interesting parts are now surrounded by an <ice:portlet> tag
              Hide
              Permalink
              Deryk Sinotte added a comment -

              My navigation test portlet also seems to work fine in JBoss so I'm marking this as fixed.

              Show
              Deryk Sinotte added a comment - My navigation test portlet also seems to work fine in JBoss so I'm marking this as fixed.

                People

                • Assignee:
                  Unassigned
                  Reporter:
                  Neil Griffin
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: