AJAX Use Cases for WSRP

AJAX Use Cases for WSRP

Subbu AllamarajuBEA Systems Inc

WSRP F2F Meeting, May 2006

Agenda

Overview of AJAX

Use cases

Common use cases

Implementing using WSRP 1.0

Implementing using WSRP 2.0

Summary

Overview of AJAX

Asynchronous JavaScript And XML

Interaction ModelRequests and responses through an XMLHttpRequest object in the browser

Typically asynchronous

Request triggered by browser events or user interactions

On various browser events, such as page reload, timer, control navigation etc.

Explicitly on user interactions, such as link clicks, form submissions etc.

Requests sent over HTTP

GET or POST requests

Response may be markup or data

Accessed as XML or text

Response handed over to a JavaScript callback

Callback processes data

Example

var request = ...; // Browser specific request.onreadystatechange = function() { if(request.readyState == 4) { if(request.status == 200) { var response = request.responseXML; // Process response } } }; request.open('GET', url, true); request.send(null);

Requests typically cause partial page changes

Browser does some level of aggregation

Browser aggregates data/markup returned via XMLHttpRequest

State encoded in other parts of the page may become stale

Standardization

Not currently a standard

IE uses an ActiveX control (IE7 supports natively)

Other browsers provide native implementations

Not all implementations support the same set of attributes and callback handlers

W3C Web API WG

http://www.w3.org/2006/webapi/

Currently focused on providing a standard interface

Mainly concerned about standardizing commonalities across current implementations in browsers

Alternatives

Remote scripting via hidden IFRAMEs is a popular alternative

For GET requests

Create a URL with query params,

Create a hidden IFRAME

Set the URL as the src of an IFRAME

For POST requests

Create a hidden IFRAME with a FORM

Submit the FORM through JavaScript

Server can return script as well as data

Works well on legacy browsers

Other alternatives

Flash, Java applets, Active X etc.

Use Cases

UC1: Fetch Data

Portlet embeds JavaScript in the markup

Submits a GET request to the server

Server returns an XML document containing the list of city codes

Portlet updates the UI with the data

User navigates to a drop-down list, and the browser fetches a list of city codes from the server

UC1 with WSRP

Portlet embeds JavaScript in its markup

Portlet uses a resource URL to submit data to the server

Can not use render URLs – render URLs may cause full page refresh

Resource URL must be rewritten by Consumer

To serve AJAX requests

[WSRP 1.0] Portlet provides an HTTP end point to serve AJAX requests

Not part of the same portlet

Does not have access to the portlet’s context or state – may have to embed all the context required within resource URLs

[WSRP 2.0] Portlet uses getResource to serve AJAX requests

Has access to the portlet’s context and state

UC2: Update Portlet Markup



Server returns HTML markup

Markup may contain rewritable content such as links and prefixes

Links in the markup do not use AJAX, and may cause full page downloads

Portlet updates the UI with the markup

User enters country code in a form, and the browser expands the form to fill in more details. Links in the expanded markup do not use AJAX.

UC2 with WSRP

Portlet uses a resource URL to submit data to the server



Encodes WSRP rewrite tokens in the return markup

Generated links can be action, render or resource URLs

Consumer proxy rewrites the markup

Consumer proxy will have to rewrite action/render URLs to cause regular interactions with the Consumer’s aggregated page

Do Consumers support this?


Portlet can generate URLs and prefixes

Use producer writing or consumer rewriting

Generated links can be action, render or resource URLs

Rewritten links can be used to interact with the consumer’s aggregated pagte

UC3: Update Portlet Markup




Markup may contain rewritable content such as links and prefixes


User continues to interact with the new markup.

Those interactions use AJAX.

User enters country code in a form, and the browser expands the form to fill country-specific markup with links. Links in this markup use AJAX to further update markup/data in the browser.

UC3 with WSRP

Portlet must use a resource URL to submit data to the server



Embeds WSRP rewrite tokens in the return markup

Generated links must all be resource URLs

Consumer proxy rewrites the markup

Any state encoded in resource URLs must be copied to new URLs created


Portlet can generate URLs and prefixes

Use producer writing or consumer rewriting


UC4: Submit Data Using AJAX


Submits a POST request to the server


Markup contain rewritable content such as links and prefixes

Form submissions cause further AJAX requests


Portlet requires a user to enter data in several forms in sequence. Each form submission uses AJAX to submit the request, and fetch the next form.

UC4 with WSRP

Portlet must use resource URLs for form submissionsUse case warrants interaction URLs – but interaction URLs may cause full page refresh.

Can not use action URLs

URLs can not include interaction state

Portlet must encode interaction state into hidden form fields or the resource URL or the resource ID

To serve AJAX requests[WSRP 1.0] Portlet provides an HTTP end point to process form submissions



Portlet can not process the request as a blocking interaction

Portlet can not ask for mode/state changes

Portlet can not update its own navigational state

Portlet can not update shared state

Portlet can fire/consume events

UC5: Page Navigation

Portlet uses AJAX to process several forms. Each form submission uses AJAX to submit the request, and fetch the next form.

Portlet provides links to navigate to previous form and next form.

A flavor of UC5

Links to previous and next forms include state to render/fetch the previous or next form

UC5 and WSRP

Use case warrants for using navigationalState to manage portlet’s view state

Not possible with resource URLs

But when encoded so, navigational state encoded outside the updated markup may become stale

Portlet can not use navigationalState to manage its current view

Portlet may lose its current state When the user interacts with another portlet on the same page

When the user refreshes the page

Portlet must manage its own stateUsing cookies – cookies set via resources may not reach the browser. When reached, cookies may not be valid per RFC 2965 rules

Using sessions – resource end point (WSRP 1.0) or the portlet (WSRP 2.0) may store the state in the session

UC6: Modal Popup

User clicks on a balance transfer link in a banking portal. Browser opens a modal dialog simulated via HTML div tags and JavaScript.

User selects accounts, and does a balance transfer.

Upon completing the transfer, browser closes the dialog, and updates account summary portlet.

Combines various flavors of previous use cases

Uses events to cause account summary updates.

Events can not be raised during resource requests

Not supported by WSRP 1.0 and WSRP 2.0.

UC7: Online Collaboration

Portlet wants to provide a collaborative quick note system.

Portlet uses a combination of polling and server push using long-lived connections.

The producer or the portlet provides for such collaboration.

Portlet uses AJAX and/or remote scripting to deliver data to the browser

Portlet can use a HTTP resource end point or getResource to return data

Summary

WSRP 1.0 Limitations

AJAX requests can not participate in the two-phase life cycle

Bypasses normal consumer-producer interactions

Must use resource URLs to serve AJAX requests

Producer must deploy an HTTP end point for AJAX requests

Portlets don’t receive portlet’s context or stateSuch info may be managed within a session on the Producer

Portlet can explicitly set its state and context in the request, and encode a key to that state in resource URLs.

Portlets must use WSRP rewrite tags for getting return markup to be rewritten

Portlets cannot make changes that are otherwise possible during performBlockingInteraction.

WSRP 2.0 Limitations

AJAX requests can not participate in the three-phase life cycle

Portlets must use resource URLs to serve AJAX requests

Deploy a HTTP end point in the WSRP 1.0 style

Or use getResource operation

Portlets receive portlet’s context or state, but may have to manage additional navigation state in a session

Portlets cannot make changes that are otherwise possible during performBlockingInteraction and handleEvents

Requirements Summary

Portlet need to embed JavaScript in its markup

Potential duplication of the script in each markup fragment

Resource URLs address only a few use cases

Consumer and Producer must fully participate in serving AJAX requests

Be able to support state changes

Be able to participate in the three-phase life cycle

Be able to update state stored in URLs in the browser

Responses be cacheable

Some Common Work-arounds

Use a new window state

Portlets add a new window state to URLs and use that to submit AJAX requests

Use a special URL parameter

Portlets add a new URL parameter to indicate to Consumers that the response must not be aggregated

Limitations

New window state applies to the entire portlet’s markup – not just to a part of the portlet’s markup

Consumers can’t push their state to the browser

Consumers won’t be able to update state stored in the browser (e.g. in URLs) outside the portlet’s markup

Consumers may be able to process events, but can’t update other portlets’ markup without a further page refresh or polling

Documents

AJAX Use Cases for WSRP