Details
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
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
Neil Griffin
created issue -
Neil Griffin
made changes -
Field | Original Value | New Value |
---|---|---|
Attachment | icefaces-portlet-4.3.0.1.war [ 10610 ] |
Deryk Sinotte
made changes -
Assignee | User Deryk.sinotte [ deryk.sinotte ] |
Ken Fyten
made changes -
Fix Version/s | 1.7 [ 10080 ] |
Ken Fyten
made changes -
Fix Version/s | 1.7DR#1 [ 10100 ] | |
Fix Version/s | 1.7 [ 10080 ] |
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #14846 | Fri Sep 21 12:25:10 MDT 2007 | deryk.sinotte | |
Files Changed | ||||
DEL
/icefaces/trunk/icefaces/core/src/com/icesoft/faces/component/NamespacingViewRoot.java
MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/application/D2DViewHandler.java MODIFY /icefaces/trunk/icefaces/component/src/com/icesoft/faces/component/portlet/Portlet.java |
Deryk Sinotte
made changes -
Status | Open [ 1 ] | Resolved [ 5 ] |
Resolution | Fixed [ 1 ] |
Ken Fyten
made changes -
Issue Type | Bug [ 1 ] | Improvement [ 4 ] |
Ken Fyten
made changes -
Fix Version/s | 1.7 [ 10080 ] |
Ken Fyten
made changes -
Status | Resolved [ 5 ] | Closed [ 6 ] |
Assignee | Deryk Sinotte [ deryk.sinotte ] |
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.