Details
Bug
Major
Description
The original liferay example works:
Download the latest Liferay sample-icefaces-sun-portlet-4.3.2.1.war http://downloads.sourceforge.net/lportal/sample-icefaces-sun-portlet-4.3.2.1.war
copy the sample-icefaces-sun-portlet-4.3.2.1.war to liferay deployment path
\home\USER\Liferay\deploy
Login to liferay, and add 2 instances of Liferay sample-icefaces-sun-portlet-4.3.2.1 on a page.
Enter an invalid email address on the portlet on the right
the validation error shows on the portlet on the right. As expected.
Now stop tomcat and copy the latest ICE faces jars to the webapps/sample-icefaces-sun-portlet-4.3.2.1/WEB-INF/lib path
el-api.jar
icefaces-comps.jar
icefaces.jar
jsf-api.jar
jsf-impl.jar
Start tomcat. When you enter an incorrect value on the right portlet, the
portlet on the left displays the validation error.
Also, unrelated problem is that the user input values are not saved when you click to a different page in liferay or select the edit icon.
Unlike the Sample JSF Sun portlet which remembers the values when you switch off the page. This is very annoying to the end user
when they loose all their edits. This happens with the old and new jars.
See the attached screen shot.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
I'm resolving this as Won't Fix as both issues are related to the Liferay sample.
First, the mixed up validation messages stem from the fact that with ICEfaces 1.7, we introduced the <ice:portlet> component for namespacing multiple portlets within a page. The Liferay examples were written for 1.6 and therefore do not use the <ice:portlet> component. I both replicated the problem as described and then fixed it by wrapping the contents of the main .jspx file in the example in <ice:portlet></ice:portlet>. By properly namespacing the contents of the two portlets, it starts to behave as it should. Liferay is aware of this and will be updating their examples when 1.7 is officially released.
The second, unrelated issue (where the contents of the form are not remembered) stems from the fact that all of the backing beans are request scoped. The example would need to be changed to provide a session scoped bean for storing the relevant data between requests.