AJAX Use Cases for WSRP

1. AJAX Use Cases for WSRP WSRP F2F Meeting, May 2006 Subbu Allamaraju BEA Systems Inc

2. Agenda • Overview of AJAX • Use cases • Common use cases • Implementing using WSRP 1.0 • Implementing using WSRP 2.0 • Summary

3. Overview of AJAX • Asynchronous JavaScript And XML • Interaction Model • Requests 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

4. 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

5. 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

6. 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.

7. Use Cases

8. UC1: Fetch Data User navigates to a drop-down list, and the browser fetches a list of city codes from the server • 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

9. 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

10. UC2: Update Portlet 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. • Portlet embeds JavaScript in the markup • Submits a GET request to the server • 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

11. UC2 with WSRP • Portlet uses a resource URL to submit data to the server • To serve AJAX requests • [WSRP 1.0] Portlet provides an HTTP end point to serve AJAX requests • 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? • [WSRP 2.0] Portlet uses getResource to serve AJAX requests • 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

12. UC3: Update Portlet Markup 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. • Portlet embeds JavaScript in the markup • Submits a GET request to the server • Server returns HTML markup • Markup may contain rewritable content such as links and prefixes • Portlet updates the UI with the markup • User continues to interact with the new markup. • Those interactions use AJAX.

13. UC3 with WSRP • Portlet must use a resource URL to submit data to the server • To serve AJAX requests • [WSRP 1.0] Portlet provides an HTTP end point to serve AJAX requests • 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 • [WSRP 2.0] Portlet uses getResource to serve AJAX requests • Portlet can generate URLs and prefixes • Use producer writing or consumer rewriting • Generated links must all be resource URLs

14. UC4: Submit Data Using AJAX 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. • Portlet embeds JavaScript in the markup • Submits a POST request to the server • Server returns HTML markup • Markup contain rewritable content such as links and prefixes • Form submissions cause further AJAX requests • Portlet updates the UI with the markup

15. UC4 with WSRP • Portlet must use resource URLs for form submissions • Use 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 • Generated links must all be resource URLs • [WSRP 2.0] Portlet uses getResource to serve AJAX requests • 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

16. 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

17. 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 state • Using 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

18. 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.

19. 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

20. Summary

21. 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 state • Such 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.

22. 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

23. 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

24. 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