Hello all, I am new with JSF and not sure if this can be done with Icefaces 1.8.2 ( + Jboss Seam 2.2)
Inside a bean method, I want to open a popup to the end user, get the answer,
and continue the method acording with the user s answer.
value="Start" id="poupupcmdId1" />
The bean method:
public void command()
boolean answer=yesno("Yes or No ?"); // here, I need to render a popup and get the answer
if ( answer)
I did tried something based on the Seam s showcase Progress Bar, but the
rManager.getOnDemandRenderer(sessionId).requestRender(); only works after the JSF lifecycle.
HTTP, J2EE and JSF are not "client/server" systems in the sense that a server can send unsolicited messages (including pop-ups) to the client. Every request must have one and only one response, and no responses may be sent without a request being made from the client. The actual limitation is in HTTP protocol, but since that's what J2EE and JSF are built on - at least for what you're interested in - the limitation applies to all of them. In actual fact, there's no long-term connection to an HTTP server at all. Each request/response is effectively a one-shot session. We use various tricks such as HTTPSession to give the illusion of a continuous conversation, but in the end, it's only an illusion.
An IDE is no substitute for an Intelligent Developer.
Joined: May 28, 2010
Hi Tim, thanks for the information, but I know a web 2 tools,named Unify NXJ(not open,and not JSF) that
has a feature like that.. I don´t know how they do, but they do...
the Icefaces (where you can send information to the browser from the server using server side async rendering ) has the ice:panelConfirmation that works great for that.
Follow the Unify NXJ´s API for their yesno function
public final int optionButtonPrompt(String message,
Prompts a message to the user during execution of an application. The optionButtonPrompt is used for prompting messages in a dialog. The dialog contains buttons for each of the options specified. Choosing a button returns the index of the option. Choosing Cancel returns -1. If the user does not respond within the specified time interval, it returns -2.
The optionButtonPrompt is used to display a prompt message with a set of buttons (one for each option, plus one for the Cancel button) used by the user to supply the answer. Choosing an option button returns the index of the option. Choosing Cancel (or closing the window) returns NXJSession.PROMPT_CANCEL (-1). If the user does not respond within the specified prompt timeout interval, the prompt is programatically dismissed and NXJSession.PROMPT_TIMEOUT (-2) is returned. If the specified prompt timeout interval is less than or equal to 0, then the prompt will not be programatically dismissed.
message - the prompt message (may include html markup).
options - the list of options to choose from.
defaultOptionIndex - the index of the option (zero-based) that should be indicated as the default.
promptTimeoutInterval - if greater than 0, the time interval (in seconds) to wait before the prompt times out; otherwise, the prompt will wait indefinitely.
index of selected option (zero-based); NXJSession.PROMPT_CANCEL (-1), if the prompt was cancelled by the user; NXJSession.PROMPT_TIMEOUT (-2), if the prompt was programatically dismissed because the user did not respond within the specified prompt timeout interval. NXJSession.PROMPT_BLOCKED (-3), if the prompt was blocked by the browser.
messageBoxPrompt(java.lang.String), optionPrompt(java.lang.String, java.lang.String, java.lang.String, int), optionListPrompt(java.lang.String, java.lang.String, int)
UnifyNXJ uses AJAX. However, it's still going over HTTP. Therefore, you can't cause a JSF Action processor to post back in the middle of a process. There flat-out isn't a way to make an HTTP server make a request back to an HTTP client. The RFC doesn't permit it. HTTP clients don't have listener IP ports, for one thing, unlike HTTP servers. Only temporary reply ports bound to outgoing requests.
The best you can do server-side to get the illusion of asynchronous operation (and it's ONLY an illusion) is offload the work to another (externally-spawned!) thread and complete the current action request, using AJAX - whether UnifyNXJ or whatever - to poll the thread for completion. Which obviously is a bad fit if you intended to do server-side confirmation, instead.