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:

  
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.

  
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.

      -Mike-