ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

Hi, no response so far on the ticket in JIRA. I've uploaded a test case with the ticket; any chance anybody can confirm this is a bug? If not, could somebody give me a pointer to how to response it?

Thanks, Bo

Hi,

I didn't solve this problem, but I DID solve the one I wanted to solve initially (=getting rid of the "user session expired" popup); it was the fault of the synchronousUpdate parameter in web.xml (should be "true")

regards, Bo

Hi,

I double checked the portlet, and it was set as asynchronous in web.xml, so I changed that to synchronous.
The error remains, the text is different:
Code:

this.elementID.asElement() has no properties
 http://localhost:8080/newpetition/xmlhttp/1213957328093/icefaces-d2d.js
 Line 30

I also can see that it's not only the cancel button (with immediate="true"), but also another button. However, the upload button of the upload component DOES seem to work.

To me it seems that the portlet, by changing to another view page, lost a reference to the connectionStatus component..

Hello,

as a solution to get rid of "user session expired" popups when it's really not expired, I read that I could place the outputConnectionStatus on the page.

This works fine, but has a side effect: a cancel button on the next page in the portlet doesn't work anymore. It seams the outputConnectionStatus interferes. In firebug I can see the following error:
Code:

[Exception... "Component is not available"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: file:///C:/Program%20Files/Mozilla%20Firefox/components/nsSessionStore.js :: sss_saveState :: line 1753"  data: no]
 file:///C:/Program%20Files/Mozilla%20Firefox/components/nsSessionStore.js
 Line 1753

I thought it might be because I only put the component on the first page of the portlet, so I also added it on the second page, with no luck.

This portlet is a synchronous one (I have 2 other portlets on the same place, one of the asynchronous); I read that in the past there's been problems with that.

Any clues to solve this issue?

Cheers, Bo

The former issue was closed, I've created a new one at http://jira.icefaces.org/browse/ICE-3087
including an example. You can vote if you have the same issue...

Cheers, Bo

I anyone wants to pick it up: I've attached the testcase.
When I deploy in liferay 4.3.3 and I access with internet explorer 6, when I go from one field to the next, the submit buttons lose their style and become ugly windows buttons.

Regards, Bo

Hello,

I've created a testcase for jira issue http://jira.icefaces.org/browse/ICE-2985
How can I upload it?
I've added a comment to the issue with the same question, but I've had no response..

cheers, Bo

Ok, maybe you can vote the jira issue...

Hi,

ordinary buttons suddenly loose their style after some interaction: they suddenly start to appear as ordinary windows buttons. (only with internet explorer 6; firefox and internet explorer 7 work fine) I've filed an issue at jira (ICE-2985)
In the meantime, has anybody faced this problem, and is there a workaround for it?

Regards, Bo

Hi,

At first the portlet shows correctly for a logged in user. However, this same portlet is also visible at the public part of the site. When I log out and access the portlet at the public part, it starts to fail. In the liferay log, I see the following error:

java.lang.NullPointerException
at com.liferay.portlet.RenderRequestImpl.setAttribute(RenderRequestImpl.java:333)
at com.icesoft.faces.webapp.http.portlet.PortletRequestAttributes.setAttribute(PortletRequestAttributes.java:28)
at com.icesoft.faces.webapp.http.portlet.PortletEnvironmentRenderRequest.setAttribute(PortletEnvironmentRenderRequest.java:164)
at com.icesoft.faces.webapp.http.portlet.PortletRequestAttributeMap.setAttribute(PortletRequestAttributeMap.java:25)
at com.icesoft.faces.context.AbstractCopyingAttributeMap.putAll(AbstractCopyingAttributeMap.java:29)
at com.icesoft.faces.webapp.http.portlet.PortletExternalContext.updateOnPageLoad(PortletExternalContext.java:188)
at com.icesoft.faces.context.View$6.portlet(View.java:125)
at com.icesoft.faces.webapp.http.servlet.ServletRequestResponse.detectEnvironment(ServletRequestResponse.java:221)

Any solution?

Regards, Bo

Hi,

as far as I know, the validation of the *current* screen is ignored with "immediate", but what I need is that the *next* screen doesn't validate.

The first time the screen is shown, no validation errors are shown, so I guess it has to do with the fact that I clear the fields.
To clear them, I use setMyField("") and getMyFieldBinding().changeText("")

Cheers, Bo

Hello,

When I have navigated through several windows (wizard-style), at the endpoint I clear the fields I've been filling in, and go back to the initial screen. When I do so, the required fields get validated inmediately, and all fields get error messages because they are empty now.

Why are they already validated? Is there a way to avoid that?

Regards, Bo

Hi,

I'm trying to submit an ice:form by javascript.

When I call:
Code:

iceSubmit(document.forms['portlet:okForm']);

I get a javascript error:

e has no properties

, line 1675 of icefaces-d2d.js

I'm using 1.7.0-beta 1

Any suggestions?

Cheers, Bo

Hi,

I don't know if the original poster means the same, but I have a similar issue: from an icefaces portlet, I need to call a servlet with some values that are stored in the portlet, in this case a list.
I think this has to be done by putting a traditional <form> form on the xhtml page, but from there on I'm not sure how to prepare the dynamic data. One of the dificulties is that the data depends on a selection criteria on the same screen (the user can chosen between dates).
I can't call it either from within the backing bean, because the servlet has to open in a separate window.

Has anybody got some hints?

Regards, Bo

Hi,

the case is easy to reproduce:
I can see a portlet when I access for the first time.
When I log out and log in again, the portlet fails (not available).
When I log out and show it on the anonymous part, it fails.

When I delete cookies while I'm on the page where the portlet is when I'm logged in, the portal asks me to log in again when I reload the page. After logging in, the portlet fails.

When I go to another page, delete the cookie, log out and log in again, the portlet is available again.

This is with Firefox. It seems that with IE it's more sensible.