voyent
Messages posted by: dsinotte  XML
Profile for dsinotte -> Messages posted by dsinotte [28] Go to Page: 1, 2 Next 
Author Message
Most ICEfaces components provide Ajax functionality automatically so no extra markup is required for default behaviour.

Documentation about the ace:ajax tag is here:

http://www.icesoft.org/wiki/display/ICE/Ajax

General tutorials are available here:

http://www.icesoft.org/java/community/tutorials-samples.jsf
I see it as well provided I click the "+" icon and drop down the viewing pane.
I recently added a comment about some of the issues of using ViewScoped beans to our Wiki that might be useful. Look for the special note under the section about changing bean scopes:

http://www.icesoft.org/wiki/display/ICE/Converting+ICEfaces+1.8+Applications+to+ICEfaces+3

This behaviour may have been fixed in a very recent release of Mojarra so you could try upgrading to see if it helps. I mention this because setting PartialStateSaving to false may have it's own problems:

http://java.net/jira/browse/JAVASERVERFACES-2636

Can you post the most markup code for the ace:menu issue?
What scope is the bean?

Does the same issue occur in a non-portlet environment (that is, if you take the same markup and bean code and just run it in Tomcat, does it behave differently)? Just trying to see if it's portlet specific.

Is it possible to replace c:forEach with ui:repeat?
That seems odd. Are you using a window-scoped bean in you application? Would it be possible to send me a simple version of your .war that shows the issue?

Looking at the code that's likely reporting the problem:

Code:
State state = (State) portletSession.getAttribute(WindowScopeManager.class.getName(), javax.portlet.PortletSession.APPLICATION_SCOPE);
 


I'm not sure why it would have problems storing and retrieving the state from the session.

When you were originally running them as two different portlets, were you using the exact same version of the ICEfaces libraries? Perhaps they were different and the serialized State instances don't match.
Are these portlets in the same .war file or different .war files? From your description it seems like they are in different .war files. What happens if you configure both portlets in the same .war? Do you see the same issue?
Good to know. I did read something to that effect in one of the JSF JIRA but haven't had a chance to test it so thank you for confirming. I did make a note about it possibly being fixed in JSF 2.1 but I'll update it to be more specific.

Our next release will be going out with official support for JSF 2.1.18+ so hopefully this won't be an issue going forward.
Thanks for your feedback. I've added a note to the pages you pointed out:

http://www.icesoft.org/wiki/display/ICE/ICEfaces+1.x+Compatibility
http://www.icesoft.org/wiki/display/ICE/Converting+ICEfaces+1.8+Applications+to+ICEfaces+3

that indicates the potential pitfalls with @ViewScoped beans.
I've opened up the following JIRA for this problem:

http://jira.icesoft.org/browse/ICE-8996

Thanks for letting us know.
The logged item is likely a known issue with recent versions of WebLogic as outlined in this recent case:

http://jira.icesoft.org/browse/ICE-8951

The workaround is simple. Just add the following to your web.xml:

Code:
     <mime-mapping> 
         <extension>xml</extension> 
         <mime-type>application/xml</mime-type> 
     </mime-mapping>
 


For the second issue (the .css value), does your markup use the resource EL syntax?

Code:
#{resource['css:styles.css']}


It seems similar to this forum user's problem:

http://www.icesoft.org/JForum/posts/list/21306.page

Looking at it again, it seems that using the #{resource} EL results in the library automatically being added to the href attribute and the OutputStyleRenderer is doing a brute force check of the attribute to make sure it ends with .css.

For the time being, you probably won't be able to use the #{resource} syntax but I'll create a JIRA ticket.
If you can provide a simple test case and the steps to reproduce, we'd be happy to take a look.
Philip has a created a test case and we've opened a JIRA for this apparent regression. Thanks for bringing it to our attention.

http://jira.icesoft.org/browse/ICE-8858
I think Philip was trying to determine if all the required .js files are being requested and downloaded. Based on the errors, it may be that it can't resolve ice.uyi.updateProperties. Is ace-yui.js being successfully retrieved?
Probably best if you provide a small test case for us to try out.

The org.icefaces.sessionExpiredRedirectURI parameter only applies if you are using the compatibility suite of components a per the note on the documentation page:

http://www.icesoft.org/wiki/display/ICE/sessionExpiredRedirectURI

Does your app behave properly on something like Tomcat or is this specific to WebLogic?
You probably want ace:pushButton or h:commandButton.

The library list looks pretty good. Some of the them are optional in that you only need them if you are using certain features.

For example, if you are only using ace: components (and not the older ice: components) then you may not need icefaces-compat-3.1.0.jar.

Also liferay-faces-alloy and liferay-faces-portal are not required unless you are using features. Basic ICEfaces portlet support only requires liferay-faces-bridge-api, liferay-faces-bridge-impl, and liferay-faces-bridge-util.
 
Profile for dsinotte -> Messages posted by dsinotte [28] Go to Page: 1, 2 Next 
Go to:   
Powered by JForum 2.1.7ice © JForum Team