ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

Most likely you need to set your mandatoryResourceConfiguration to either be "all" or include "fileEntry".

http://wiki.icesoft.org/display/ICE/mandatoryResourceConfiguration

When fileEntry uploads the file, it all happens in a single lifecycle, so there is no first lifecycle to unrender components then second lifecycle to render them again. You would have to intercept the form being submitted, in javascript, and use CSS to stop displaying whichever portions of the browser dom, and then after the upload revert the CSS hiding.

With ICEfaces1.8.x, the Renderer classes that we use to override the rendering for the h: components exists here:

icefaces/core/src/com/icesoft/faces/renderkit/dom_html_basic/

And the Component and Renderer classes for our ice: components are here:

icefaces/component/src/com/icesoft/faces/component/

You'll notice that the Custom Component have their own individual folders there, and the Enhanced Components (ice: components that correspond to an h: component) are within the ext folder.

Ahh, as soon as you said rowSelector, I was going to recommend what you did :)

The constant posts are probable from using server push to update the view. If you look in your web.xml file there's probably a context-param talking about synchronous mode. If you flip that value, so that you're not longer using asynchronous, but are instead using synchronous, that should turn off server push. But your website might rely on that feature... So that might just be helpful when you're debugging and not a change for production.

One thing is that the commandSortHeader goes into the column component's "header" facet.

The FileEntryPhaseListener does its work pre-RestoreView, which is before Facelets construction. But, a file upload can only happen on a postback after the fileEntry component has already been shown. So, if you can conceive of a way of using your Facelets ui:param to specify the bean, and save that somewhere, such as possibly a page parameter, hidden form field, or elsewhere, that will be accessible in the request parameter map or some other place that's EL available in pre-RestoreView, then it might still be possible to use the callback functionality.

Our support staff have access to dom differencing diagnostics that shows what the root cause of an update is. They need to run the test application themselves to determine why the update is involving the whole page.

Is there some reason why the ice:commandSortHeader needs to be programmatically created with Java code, instead of just adding it to the view with <ui:include> or setting rendered=true, or something using the .xhtml/.jspx view definition.

That's more something to test to see if that's the problem at all. Depending on the test results we can come with ideas for solutions.

You should be able to use a debugging and set a breakpoint, and not have to modify the code.

Also, it's relevant to know the basic structure of the page. Is the popup inside the same form as the dataTable, or are they separate forms?

Sorry, I don't really work with our plugins. But for the link I posted, to the ICEfaces 1.8.2_P03 EE release, I believe this is the appropriate Eclipse plugin:

ICEfaces-EE-1.8.2.GA_P03-Eclipse-3.6_3.7.zip

which you can find here:

http://www.icesoft.org/downloads/icefaces-1.8-downloads.jsf

Interesting.. So it sounds like something else than I'd thought. Try using an h:inputTextarea, instead of the ice:inputTextarea.

For Firbug, go to the Net tab, and it will show all your GETs and POSTs. After the page loads, click Clear to clear away all the GETs, and then do your interactions with the components. It will show you what was submitted and what the response was, for each submission. You can copy from there and paste it in here.

I believe this might be an instance of an issue I've seen before.

http://jira.icefaces.org/browse/ICE-6470
http://jira.icefaces.org/browse/ICE-6584

There might be two server posts happening, one when you onblur away from the inputtextarea component, since it uses partialSubmit, and one when the commandButton submits the form.

Definitely get rid of the component binding, and go with a ValueExpression for the inputTextarea's value property to the bean. But also verify with Firebug or whatever developer tool you use with your browser, if two posts are happening. You can also test with removing the partialSubmit property on the inputTextarea. If making those two changes doesn't stop the inputTextarea from getting cleared, then we're dealing likely with something else.

You can test with the newest EE version of ICEfaces 1.8.2 from here:

http://www.icesoft.org/downloads/detail-1-8.jsf

Take a look at: org.icefaces.ace.component.fileentry.FileEntryFormSubmit and see if this code is still executing in your scenario. It watches for a form to be added to the view, and looks within it for a fileEntry. Since you add your fileEntry differently, and possibly too late, you may need to kick off this code or an equivalent.