Re: [wsrp] Ajax and JSF

[Subbu Allamaraju <subbu@bea.com>]

Mike - have you discussed the possibility of custom bridges that go 
along with specific toolkits? Looking at some of the JSF toolkits, it 
seems reasonable to abstract out some of the toolkit specific Ajax 
params within a bridge.

Subbu

Michael Freedman wrote:
> 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.
>       -Mike-

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.