Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve Ajax and modal dialog support in Web Flow to be more universally useful regardless of client-side technology [SWF-1390] #577

spring-operator opened this issue Aug 27, 2010 · 0 comments


Copy link

spring-operator commented Aug 27, 2010

Rossen Stoyanchev opened SWF-1390 and commented

Web Flow supports a popup attribute on a view state that causes the view to be rendered in a modal dialog. This works even with state transitions. However the feature is only available when making Ajax requests with Spring Faces components or with Spring JavaScript and Dojo. The purpose of this ticket is to make it easier to work with modal dialogs in Web Flow regardless of the client-side technology or JSF component library used.

Background: by default Web Flow issues a client-side redirect to transition between states and that's regardless of whether the request is Ajax or not. For Ajax requests made with Spring JS (or Spring Faces components), Web Flow returns special response headers that are then processed browser-side (with the help of Spring JS) by following the redirect in a second Ajax request.

A challenge with this approach is it requires client-side support to process instructions from the server sent in the form of custom response headers. This makes the feature unavailable for use with other JSF component libraries or where the client-side technologies other than Spring JS (and Dojo).

There are also limitations on a few related scenarios:

  1. A modal dialog that transitions without full page refresh - a modal dialog transitions to other view states with a mandatory redirect and a full page refresh; that precludes bringing up a modal dialog to get some input and then returning to the underlying page without re-rendering in full

  2. A modal dialog over several transitions - a modal dialog can only be used with a single view; a transition to anther view having popup="true" results in a second modal dialog; hence it isn't possible to go through several views in one modal dialog

  3. Ajax flow embedded on a page - there is no way for a flow to work embedded on a page without causing updates to the entire page

The following JIRA tickets have also been reported based on experience with the feature:
#233 specify popup on the transition element
#408 improve popup use when "submit level" validation occurs in the popup
#500 issue when having a pop-up on top of another one
#514 WebFlow - bug when working with RichFaces components inside a popup
#287 Ajax web flow wizard
#454 <view-state> tag - popup="true" should support expression language

The key pieces of the improvement would be:

  1. View A makes an Ajax request and transitions to view B without a client-side redirect. That will remove the requirement for the client-side to deal with a redirect.

  2. View B does partial rendering. The <render fragments=".."/> action can be used to control what is rendered in combination with Tiles or JSF 1.2. For JSF 2, preliminary tests show that a partial response in view B can be generated based on a request initiated from view A.

  3. Client-side code processes the partial response and updates the DOM.

  4. Optionally a modal dialog is launched.

Note that step 4 is easily achieved with JSF component libraries that commonly provide a modal dialog component. The technique involves defining the modal dialog component in view A with an empty placeholder inside it. Step 3 then replaces the empty placeholder inside the modal dialog and brings it up when the Ajax request completes. The contents of the modal dialog can be continuously updated over subsequent Ajax requests and view state transitions.

Additional thought must be given to this feature in JSF environments since essentially the client-side DOM will contain content from two views and hence two component trees. I believe as long as partial rendering remains on the granularity of a form then each form on a given page can post back successfully to the view state it is associated with (as evidenced by use of Spring Faces Ajax requests in combination with transition to view state having popup="true").

Affects: 2.1.1

Issue Links:

4 votes, 4 watchers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

1 participant