Win a copy of TDD for a Shopping Website LiveProject this week in the Testing forum!

Brian Stock

Greenhorn
+ Follow
since Jun 04, 2012
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Brian Stock

I believe I understand what you're saying. If you read my post carefully, I tried to only refer to "pushing" as the illusion provided by the ICEfaces (ICEpush) abstraction layer. ICEfaces is still polling under the hood (which you can see by inspecting in Firebug), but PushRenderer/PortableRenderer allow the developer to perceive the illusion of "pushing" from the server by setting a flag for the poller to pick up.

Now that I understand the inner workings, I can see why you need to spawn a new thread in order to do what I want. Thank you very much for helping me understand.
9 years ago
JSF
Thanks for the insightful post.

Please correct me if I am mistaken, but if I understand you correctly, ICEfaces, or specifically ICEpush (http://www.icesoft.org/projects/ICEfaces/ajax-push.jsf) abstracts the client polling so that it gives the illusion of a server "pushing" DOM objects to the client browser, while it is in fact the client browser periodically polling the server for new DOM objects. The problem I am experiencingi s an artifact of this illusion. If the PushRenderer.render("someGroup"); is called from an existing HTTP request, it has to wait for it to complete to update the browser, and it won't complete until the long processing is done.

What I need to do is spawn the long processing task in a seperate thread, and call PushRenderer.render("someGrounp); from that thread, after somehow passing it the correct PushRenderer context.
9 years ago
JSF
from: http://stackoverflow.com/questions/10883133/how-can-a-jsf-icefaces-components-parameters-be-updated-immediately

I have an ICEfaces web app which contains a component with a property linked to a backing bean variable. In theory, variable value is programitcally modified, and the component sees the change and updates its appearance/properties accordingly.

However, it seems that the change in variable isn't "noticed" by the component until the end of the JSF cycle (which, from my basic understanding, is the render response phase).

The problem is, I have a long file-copy operation to perform, and I would like the the inputText component to show a periodic status update. However, since the component is only updated at the render response phase, it doesn't show any output until the Java methods have finished executing, and it shows it all changes accumulated at once.

I have tried using FacesContext.getCurrentInstance().renderResponse() and other fucntions, such as PushRenderer.render(String ID) to force XmlHttpRequest to initialize early, but no matter what, the appearance of the component does not change until the Java code finishes executing.

One possible solution that comes to mind is to have an invisible button somewhere that is automatically "pressed" by the bean when step 1 of the long operation completes, and by clicking it, it calls step 2, and so on and so forth. It seems like it would work, but I don't want to spend time hacking together such an inelegant solution when I would hope that there is a more elegant solution built into JSF/ICEfaces.

Am I missing something, or is resorting to ugly hacks the only way to acheive the desired behavior?

9 years ago
JSF