OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Ajax and JSF

During last weeks JSR 301 F2F we discussed Faces Ajax support in the context of Portlets/Bridge.  A number of things to note:
    a) there are a variety of strategies for using Ajax in Faces.  We need to expand our search and plan to accommodate a variety.
    b) One common pattern is to implement "partial page refresh".  In this pattern a regular Faces action is submitted.  Data submitted with the action indicates an ability to restrict processing to only a particular part of the Faces view.  I.e. in simple terms the action is submitted to a regular Faces view, however processing is optimized by only running over the necessary branch of the the view tree. In this pattern:
  1. The data identifiying this as a partial page refresh request and the portion of the page that is being targeted is proprietary/private to the Faces/Ajax implementation.
  2. The execution expects to complete in a single request lifecyle.
    In discussing this last week we think some of the consequences are that (a) JSR 286 expect the target of Ajax requests to be actionURLs not resourceURLs (b) JSR 286 not impose/expect Faces to set any type of fragment ID (c) JSR 286 not impose/define new URL data scope to deal with the single request lifecycle issue.  Though the single request lifecycle is needed by Faces it probably prefers a solution that allows the resulting code to continue to be container independent.  I.e. Faces developers prefer to not have to check to see if they are running in a Portal/Portlet environment and change the way they submitt/encode some of the data for the Ajax request.  Rather, there seemed to be a preference that JSR 286 define that such actionFragment requests be guaranteed to complete (along with rendering) within a single request lifecycle.  I.e. be stricter then regular actions.  This of course assumes that the consumer can decide to abort/ignore the Ajax result after the fragmentAction and force a full/regular render if the result of the action has side effects that make the response obsolete.

  c) Faces (and I am sure others) would like to hear details of how Ajax/javascript versions will be dealt with within the emerging model.  It was pointed out that though a simple solution of having each portlet isolate its javascript in its own namespace seems technically correct it suffers when there is a common javascript/rich client environment as other rich client behaviors such as drag-drop will likely break.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]