© 2008 ibm session id: d03 title: web 2.0, ajax, and rest for wp 6.1 speaker: adam cook, ibm...

© 2008 IBM

Session ID: D03Session ID: D03Title: Web 2.0, AJAX, and REST for WP 6.1Title: Web 2.0, AJAX, and REST for WP 6.1

Speaker: Adam Cook, IBM Software EngineerSpeaker: Adam Cook, IBM Software Engineer

WebSphere Portal Technical Conference U.S. 2008

STORY TITLE

2WebSphere Portal Technical Conference U.S. 200822

Agenda

Introducing the new Web 2.0 features

Using AJAX and REST in a portal environment Challenges Web capabilities

Developing themes using AJAX and REST Client-side aggregation The PortalWeb2 theme

Developing AJAX portlets AJAX support in JSR 286 and WSRP 2.0 HTTP proxy for AJAX applications Client-side portlet programming model

STORY TITLE


Self-establishing Communities collaborating around topics of common business interest

Support User Contribution, treat users as co-authors and leverages their skills

Accumulation of user knowledge to make apps smarter themore people use them

Enable users to add value by adding meta data,e.g. rate, tag, bookmark, comment

Allow users to Take Control and let themmake applications most useful to them

Separate User Interface from Services to makeservices re-usable

Fine grained access to data supporting mashups Mashups combining existing services into new,

useful applications joining information Situational Development of applications through line

of business can help make businesses more agile AJAX to enable rich, interactive, highly responsive Web UI Use of Semantic Tags and Microformats to enable dynamic augmentation

with contextual menus or information

Web 2.0 Concepts interesting for Enterprise Use

STORY TITLE


The new Web 2.0 Features at a Glance

Portal REST services Separate portal user interface from portal data Access to portal models (content, navigation, layout), preferences and user

profiles Client-side aggregation and customization

Mashup application using Portal REST services Improved user experience and performance

AJAX portlet development AJAX portlet programming model extensions based on Dojo+IBM

extensions AJAX proxy to manage /restrict access to other domains

Semantic tagging Allow smart markup to enable value add by portal, e.g. dynamic menus Client-side Click2Action based on semantic tagging to enable cross-portlet

interaction locally in the browser or with server side code Client-side feed consumption

Highly efficient integration of information through feeds (Atom and RSS) Integration, aggregation and customization of Google Gadgets

© 2008 IBM


Using AJAX and REST in a Portal EnvironmentUsing AJAX and REST in a Portal EnvironmentChallengesWeb Capabilities

STORY TITLE


Main Challenge: Supporting Web Capabilities

AJAX bypasses standard browser paradigms and Web capabilities E.g. back button, bookmarkability, reload, caching, crawlability Requires extra effort to get these capabilities working again

In a portal environment this is even more challenging Components (typically portlets) are combined with other components into a

larger portal application URLs can no longer be generated in an isolated manner as a portal URL needs

to encode the navigational state of the entire portal page Navigational state is the aggregation of

• Portal state: Page selection, theme template, etc.• Portlet states: Render parameters, portlet mode, window state

Restrictions due to navigational state behavior AJAX is tailored towards replacing fragments on a page

• This leads to problems with navigational state as it is part of every URL As a consequence, portlets cannot simply create URLs that change navigational

state / render parameters Navigational state changes require support from a portal-aware Javascript

library

• Conceptually, every URL on the page needs to be updated

STORY TITLE


Supporting Web Capabilities (cont.)

Capability Web 1.0 Web 2.0

Bookmarkability A user can create a browser bookmark from any link on a page. Each link contains the latest navigational state of all portal artifacts visited so far.

Available through different means

Can be supported with a special „Bookmark this page“ link. A user would have to select this link to create a URL that is bookmarkable.

Back Button Forward Button Reload

A user can navigate using the browsers back, forward and reload button with the expected behavior (e.g. like static html pages).

Limited support available

Javascript Frameworks such as Dojo support back and forward button in a limited fashion. It is not working in Safari and for the reload scenario. The history of back and forward button is also not working as expected from the Web 1.0 behavior.

Multiple Browser Window Support

A user can open multiple browser windows or tabs and navigate through portal independently using any link on the page. Every window/tab has its own state.

Partially available

A user can open a new browser window or tab to a new view. However, true independent navigation is not possible. The latest view will always be shown in the window the user navigates last.

STORY TITLE


Supporting Web Capabilities (cont.)

Capability Web 1.0 Web 2.0

Crawlability The markup that is returned from a portlet is analyzed by the search engine. Best practice is to return special markup when a portlet is accessed by a search engine. For simple portlets this might not be required.

Not available

An AJAX portlet needs to be enabled explicitly by returning markup directly on the server side. The search engine does not understand Javascript.

Browser & Reverse Proxy Caching

The full portal page is cached in a reverse proxy or browser cache. Therefore the page expires with the time of the shortest expiration of all artifacts on the page. Artifacts with a long expiration time would still be loaded in this case.

Available

Each artifact on the page is loaded on demand from within the browser. Therefore, the reverse proxy and browser cache hold each artifact on its own with the maximum effect for cachability. When an artifact never expires it is not loaded again with follow-on request.

© 2008 IBM


Developing Themes using AJAX and RESTDeveloping Themes using AJAX and RESTClient-side aggregationThe PortalWeb2 theme

STORY TITLE


Motivation for applying AJAX in a Theme

A portal page is normally composed of lots of fragments Header, footer Navigation Toolbars Portlets

User interaction will typically only affect a single portlet Lots of situations where applying AJAX makes sense!

STORY TITLE


Client-side Aggregation (CSA)

A new method of rendering a portal page Browser-side page aggregation, navigation and customization

Accesses and manipulates portal information through REST services Renders XML obtained from the server on the browser side Implemented using AJAX, XML, Dojo, and JavaScript

Superior user experience Highly reactive and direct user interface Many actions possible without server roundtrips Avoids page flickering

Improved performance and scalability Reduced server side processing – offloads rendering workload to browser Reduced bandwidth requirements between server and browser Reduced client-side processing – mostly fragment reloads, few page reloads Improved HTTP caching – all artifacts can be cached independently

STORY TITLE


Architecture

CSA framework conntects to server-side REST services (Remote Model API) Returned model feeds are typically based on the ATOM format (application/atom+xml) URL pattern „/wps/mycontenthandler/...?uri=nm:oid:wps.content.root&levels=2...“

Application interactions* are processed by portal servlet (stateful requests) URL pattern „/wps/myportal/!ut/p/c5/04_SB8K8xLLM9MSSzPy8xBz9CP…”

Several intermediary caches might be involved

*) also applies to full page refresh requests

DOM

CSA

Fram

ew

ork REST

Servlet

Bro

wse

r Cach

e

ApplicationInteractions

HTML, XML

RESTRequests

XML

UI Events

DOM

Update

Pro

xy C

ach

e

Browser Server

EnginePortalServlet

PortletContainer

Navig.Model

ContentModel

PortletModel

LayoutModel

Opera-tions

...

*) also applies to full page refresh requests*) also applies to full page refresh requests

STORY TITLE


The PortalWeb2 Theme

Sample theme that supports client-side aggregation Starting point for all CSA themes Can be copied and adapted gradually

Can be rendered in CSA mode and SSA mode Reason: Not every portlet will work in CSA mode Theme switches to SSA mode in such a case („SSA fallback“)

Theme elements relevant for CSA mode A skeleton HTML document containing placeholders A JS bootstrap function which gets called after the page finished

loading• Calls CSA framework to initiate the CSA rendering process• During rendering process, placeholders are replaced with markup

In SSA mode, proceed with traditional JSP-based rendering<div id="wptheme-topnav"> <c:if test="${!renderPlaceholdersOnly}"> <%@ include file="./topNav.jspf" %> </c:if></div>

STORY TITLE


Packaging

UI widgets + eventing

Encapsulates communication with

server-side REST services

DOM update

Client-side state handling

Click interception

Convenience APIs

CSA Framework

Uses CSA framework,in particular UI widgets

Widget templates (XSL)

CSS, images, icons

PortalWeb2 theme

STORY TITLE


Portal vs. PortalWeb2 Theme

Both themes look the same but feel differently

Theme „Portal“ supports SSA mode only

Only a few files were modified

head_extra.jspf initializes CSA and initiates bootstrap

js.jsp loads CSA-specific libraries (e.g. Dojo)

status_bar.jspf defines HTML anchor for status bar

Some new files and folders xsl folder contains XSL

templates producing the widget markup

CSAProperties.jspf loads resource bundle strings needed by CSA (allows to use dojo.i18n APIs)

head_themePolicy.jspf stores current theme policy in a JS variable

STORY TITLE


Client-side Rendering

Client

ServerJSP-basedRendering

DOM /HTML CSA JS Framework

Bootstrap (onload)

Page Aggregator

TopNav Page

SideNav Portlet

XSL

REST Framework

XSL

XSL XSL

NavigationModel

LayoutModel

...

HTML skeleton+ JavaScript

onload

renderDOM updat

e

Load navigation model feed

1

2

3

4

Based on JS widgets instantiated during bootstrap (based on theme policy)

Widgets connect to server-side REST services

Widgets apply XSL templates to the XML returned by the server to produce the markup (MVC)

Widget injects the markup into the corresponding placeholder in the DOM

The markup of a widget might contain placeholders which are again replaced with markup produced by other widgets

STORY TITLE


Bootstrap

Bootstrap(onload handler)

NavigationalState Controller

PortalAggregator

Event Broker

com/ibm/portal/aggregation.jscom.ibm.portal.aggregation.PortalAggregator

Register widgets accordingto theme policy

Set current state thatshould be rendered

fire stateChanged event

WidgetWidgetWidgetInvoke render()

function ofregistered widgets

Invoke callback functions registered for stateChanged event

com/ibm/portal/navigation/controller.jscom.ibm.portal.navigation.controller.NavigationalStateController

onload

Bootrap function defined in head_extras.jspf Executed via onload handler Initializes PortalAggregator with widgets according to theme policy Sets current navigational state on NavigationalStateController to initiate

rendering of widgets

STORY TITLE


XSL Templates used in CSA

Server-side rendering Client-side rendering

Top Navigation topNav.jspf xsl/topNavRender.xsl

Side Navigation sideNav.jspf xsl/sideNavRender.xsl

Page Layout Home.jsp /UnlayeredContainer*.jsp

xsl/mainContentRenderLayout.xsl

Portlet Decoration /Skins

Control.jsp xsl/IBM.xsl, xsl/NoSkin.xsl

In SSA, the complete page markup is generated by JSPs Typically there is one JSP fragment for each theme element

In CSA, JavaScript widgets are used Widgets generate markup by applying XML templates to the XML

representing the model the widget is bound to The PortalWeb2 theme provides one XSL file for each theme element

STORY TITLE


Customizing the PortalWeb2 Theme

com/ibm/portal/aggregation/theme.jscom.ibm.portal.aggregation.theme.NavigationElement

function bootstrap() { ... var portalAggregator = com.ibm.portal.aggregation.PORTAL_AGGREGATOR; ... portalAggregator.navigation.addNavigationElement(new com.ibm.portal.aggregation.theme.CrumbTrail() ); ...

Modifying the widget markup Adapt the XSL files accordingly

Re-arranging theme elements Edit Default.jsp; re-arrange the widget placeholders accordingly

Adding new theme elements Add a placeholder to a theme JSP using a DIV tag with an id attribute Write a Javascript controller object (=the widget) that extends the base

widget

Write an XSL template to separate view from controller (optional) Edit head_extras.jspf to register the new widget with the portal aggregator

object during bootstrap:

STORY TITLE


Skins

“Actions” toggles Portlet Mode and Delete actions

Selecting a mode will render that mode inline

Note that view mode is still displayed

Skins are registered during bootstrap like other widgets Implemented as JavaScript widgets

Markup generation done via XSL Each skin generates a placeholder DIV for the portlet‘s markup

com/ibm/portal/aggregation/skin.jscom.ibm.portal.aggregation.Skincom.ibm.portal.aggregation.IbmSkin

STORY TITLE


Portlet Interactions

Portlet related DOM events (e.g. a click on a portlet link) are intercepted by CSA and processed via an asyonchronous AJAX request

Portlet markup is embedded into an XML response (+ meta information); CSA framework injects markup into DOM residing in the browser

CSA detects dependencies between portlets automatically Dependencies due to navigational state changes, in particular shared render params Dependencies due to server-side communication between portlets

• JSR 286 eventing• Property broker• Shared portlet session

Click

event

In CSA, a portlet interaction typically does not cause a full page refresh

Instead, only the portlets that are affected by an interaction are refreshed using individual requests.

STORY TITLE


SSA Fallback

Portlets might be incompatible with CSA due to Javascript conflicts Non-standard coding practices Insufficient browser capabilities

SSA mode can be enforced via Portlet initialization parameter (portlet.xml)

Page parameter /meta data (Edit Page Properties)

Note that for Administration, Web Content, and Personalization pages SSA mode is enforced by default

Portlet blacklist (PortalWeb2/js/portletsForServerSideOnly.js)Add the portlet definition UID (defined in portlet.xml) to the listNote that the init parameter approach should be preferred; the blacklist was created for portlets that have been shipped already

com.ibm.wps.web2.renderMode=force_SSA

RenderMode = force_ssa

STORY TITLE


Re-enabling the Back Button and Bookmarkability Back /Forward Button

CSA framework tracks state history (on the client) When reveiving a back /forward event, the respective state is loaded Works as long as CSA is not left, i.e. does not work across CSA SSA

or SSA CSA changes

Bookmarks Browser capability cannot be used because AJAX bypasses browser

address bar The PortalWeb2 theme offers a „Create Link to this Page“ link which

can be used instead

STORY TITLE


Summary CSA considers portlets as page fragments that are reloaded

individually No special programming required inside the portlet

May occasionally conflict with JavaScript handling inside the portlets E.g. dynamically generated HTML FORMs, onLoad handlers

Portal is doing the AJAX handling Tracks and updates state across all portlets Refreshes multiple portlets in case of inter-portlet communication (or

even the entire page if necessary) Closely integrated with the server-side implementation to find out

which portlets were affected by a request

Improved performance Capacity Planning Scenario Throughput +40%, -10% garbage and -45% CPU utilization per

transaction

But: CSA /PortalWeb2 theme is not an all purpose solution! Carefully decide whether it makes sense to use CSA depending on

Caching characteristics of pages and portlets (markup) User behavior Implementation technologies /frameworks used by portlets

© 2008 IBM


Developing AJAX PortletsDeveloping AJAX PortletsAJAX support in JSR 286 and WSRP 2.0HTTP proxy for AJAX applicationsClient-side portlet programming model

STORY TITLE


Using AJAX in Portlets – Scenarios

Data Retrieval Client loads data and displays it without changing the view Examples

Typeahead feature: A user enters text into a text field and receives tips or auto-completion about the entered text

Refreshing stock quotes: A portlet displays the latest stock quotes every five minutes

Markup Retrieval Client loads markup with the purpose of displaying a new view or

loading data and transforming this into markup/DOM Examples

A servlet /portlet is accessed and the returned markup is being used to replace the current view in the DOM

A REST Service returns an ATOM feed which is converted into markup /DOM using XSLT

STORY TITLE


Using a Servlet to connect to an External Data Source

Portal WAR

Portal Server

WAR

Portlet

WAR

Serv

let Servlet

Browser

ClickJS

Portlet

WAR

WAR

Portlet

WAR

WAR

Portlet

WAR

HTTPSession

e.g. XML /HTML

External Server(e.g. Mail Server)

Portlet WAR contains one portlet and one servlet Servlet acts as a proxy that connects to the external data source Servlet is needed to overcome same origin policy

Portlet is embedded into markup like any other portlet Servlet is directly accessed through Javascript in portlet markup Portlet can pass data to the servlet using the session (app. scope)

Possible in WP 6.0 already

STORY TITLE


Servlet Approach: Conclusions

Portlet is doing the AJAX handling Works on any standards-compliant portal Portlets usually need AJAX Javascript libraries – watch out for conflicts!

Useful for data retrieval and update In particular useful, if portlet displays content from a different source anyway

(e.g. from mail server) Can be used to update backend data and clean server-side caches if necessary

AJAX call cannot use portlet APIs or affect the portlet state View changes are typically lost in case of a full page refresh

Implementation of servlet might get tricky In particular if servlet is used to connect to several different data sources Servlet actually needs to act like a real HTTP proxy

Handling of cookies, redirects, request /response headers etc. required Connection pooling to avoid performance bottleneck Security considerations......

STORY TITLE


Using the AJAX Proxy to connect to an External Data Source

AJAX Proxy

Portal WAR

Portal Server

Serv

let

Browser

ClickJS

e.g. XML

External Server(e.g. Mail Server)

Portlet

WAR WAR

Portlet

WAR

WAR

Portlet

WAR WAR

Portlet

WAR

Similar to servlet-based approach AJAX proxy

Manages access to other domains Allows to specify access policies HTTP proxy which handles cookies,

headers, redirects etc.

Possible in WP 6.1

AccessPolicyAccess

PolicyAccessPolicy

STORY TITLE


Portal server in domain A

Server in domain BBrowser

Portal pagefrom domain A

AJAX Proxy

Background: Same origin policy Prevents client-side scripts from loading content from a different domain Inhibits cross-site scripting Sample: Portlet served from myportal.com tries to load a feed from cnn.com using

XHR

HTTP proxy for AJAX applications Servlet-based HTTP proxy which routes requests to trusted target domains Responsible for cookie rewriting, content type filtering, connection management etc. Allows security admins to manage access to other domains Whitelist approach – Trusted sites need to be „unlocked“ explicitly

JavaScript

HTTP GET HTTP GETAJAX proxy

filter chain

AccessPolicy

STORY TITLE


AJAX Proxy Configuration

Proxy configuration specified in proxy-config.xml Global configuration vs. application-specific configurations

Global configuration can be updated during runtime A portlet can provide its own

proxy-config.xml file Security admins can disable

application-specific configurations

<?xml version="1.0" encoding="UTF-8"?><proxy-rules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:proxy="http://www.ibm.com/xmlns/prod/websphere/portal/v6.0.1/proxy-config"> <proxy:mapping contextpath="/proxy" url="*" /> <proxy:policy url="*"> <proxy:actions> <proxy:method>GET</proxy:method> <proxy:method>HEAD</proxy:method> </proxy:actions> </proxy:policy> <proxy:meta-data> <proxy:name>max-connections-per-host</proxy:name> <proxy:value>5</proxy:value> </proxy:meta-data> </proxy-rules>

<?xml version="1.0" encoding="UTF-8"?><proxy-rules xmlns:xsi="..." xmlns:proxy="..."> <proxy:mapping contextpath="/ibm" url="http://w3.ibm.com" /> <proxy:policy url="http://w3.ibm.com/ibm/values/*"> <proxy:actions> <proxy:method>GET</proxy:method> <proxy:method>HEAD</proxy:method> <proxy:method>POST</proxy:method> <proxy:method>PUT</proxy:method> </proxy:actions> </proxy:policy> <proxy:policy url="http://w3.ibm.com/bluepages/*"> <proxy:actions> <proxy:method>GET</proxy:method> <proxy:method>HEAD</proxy:method> </proxy:actions> <proxy:mime-types> <proxy:mime-type>text/html*</proxy:mime-type> <proxy:mime-type>application/xml*</proxy:mime-type> </proxy:mime-types> <proxy:cookies> <proxy:cookie>LTPA</proxy:cookie> <proxy:cookie>CoreID</proxy:cookie> </proxy:cookies> <proxy:users> <proxy:user>AllAuthenticatedUsers</proxy:user> </proxy:users> </proxy:policy></proxy-rules>

STORY TITLE


AJAX Proxy Programming Model The proxy programming model defines

how to make requests (e.g. how to format URLs that should address the proxy)

how the proxy reacts in a specific case (e.g. in case of an error)

REST-based URL format

Examples (depends on context path mapping)

Status codes 200 OK – Request was accepted by the proxy and target host returned 200 400 Bad Request – Syntax of the request was not correct 403 Forbidden – The request was not accepted by the proxy (no matching

policy) or basic authentication failed 404 Not found – Request was accepted by the proxy but target server did

not respond or returned a 404 302 Found – After successful authentication

<protocol>://<portal-domain>/<proxyurl>/<protocol>/<host>%3a<port>/<url>?<query>

http://www.ibm.com/developerworks/news/dw_dwtp.rss http://myportal.com:10038/wps/proxy/http/www.ibm.com/developerworks/news/dw_dwtp.rss

http://www-01.ibm.com/software/swnews/swnews.nsf/swnewsrss?openview&RestrictToCategory=lotus http://myportal.com:10038/wps/ibmsoftwarenews/swnews.nsf/swnewsrss?openview&RestrictToCategory=lotus

STORY TITLE


Evolution of Portlet Standards

Current Java Portlet Specification (JSR 168) aimed at a 60% target Support most common use cases Agree on basic functionality quickly Defer advanced functionality to later standard versions

More functionality in Java Portlet Specification 2.0 (JSR 286) http://jcp.org/en/jsr/detail?id=286 Equivalent standards update for remote portlets: WSRP 2.0 http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-spec.html

Key capabilities introduced with JSR 286 Events: Enable portlets to communicate with each other through sending and

receiving events Shared render parameters: Enable portlets to specify which render

parameters they can share with other portlets Resource serving: Enables portlets to serve resources within the portlet

context using resource requests

WebSphere Portal 6.1 supports JSR 286 and WSRP 2.0

STORY TITLE


Resource Requests

New callback interface triggered by so-called “resource URLs” serveResource(ResourceRequest, ResourceResponse)

Allow portlets to render stand-alone content No portal page aggregation, no theme content Portlet has full control of the entire output, and access to all APIs and state

data(e.g. portlet session)

Generate binary content (PDF, SVG etc.) Pop-up windows

Allows for limited AJAX support inside portlets Portlets now have a way to return XML, JSON, HTML fragments or other

content Better programming model than packaging a servlet in the same WAR file

STORY TITLE


AJAX using JSR 286 Resource Serving

AJAX-enabled portlet reloads affected content using a resource request AJAX call handled inside the portlet Can be implemented using JSR 286 Possible in WebSphere Portal 6.1

Portal WARXHR +

resource URL

Portal Server

Portlet

WAR WAR

Portlet

WAR

WAR

Portlet

WAR WAR

Portlet

WARServ

let

Browser

Click

JS

XML /HTML etc.

serveResource

STORY TITLE


AJAX using JSR 286 Resource Serving – Conclusions Again, only portlet is responsible for AJAX handling

Portal does not know what is going on and who is affected

AJAX call can be handled inside the portlet Portal APIs are accessible Current state (navigational state, preferences, portlet session) can be

accessed Can update preferences and portlet session in a POST request

Only limited functionality available Cannot update navigational state and send events etc.

STORY TITLE


Portlets using the Client-side Portlet Programming Model

Portal WAR

Portal Server

Portlet

WAR WAR

Portlet

WAR

WAR

Portlet

WAR WAR

Portlet

WAR

Serv

let

Browser

Client-side portalframework

Click

JS

Portlet API REST

Other

User Profile

Preferences

XMLPortletRequest

Preferences

Nav. State

User Profile

DB

Request

RequestPref. feedRequestUser Prof. feed

XML /HTML

Full AJAX support through client-side portlet API Convenience JavaScript APIs simplifying AJAX portlet development AJAX calls handled by the portlet and the portal Solution which even handles navigational state and intercommunication

properly Possible in WebSphere Portal 6.1

STORY TITLE


Getting Access to the API

dojoportal.declare("ibm.portal.portlet.PortletWindow", null, {

// Constructor initializer: function (/*String*/ windowid) {...},

// Function to create a new XMLPortletRequest newXMLPortletRequest: function() {...},

// Functions to read /write navigational state (portlet mode, window state, render parameters) getPortletState: function(/*Function*/ callbackfn) {...}, setPortletState: function(/*PortletState*/ state, /*Function*/ callbackfn) {...},

// Functions to read /write persistent state (portlet preferences) getPortletPreferences: function(/*Function*/ callbackfn) {...}, setPortletPreferences: function(/*PortletPreferences*/preferences, /*Function*/ callbackfn) {...},

// Functions to read /write user profile information getUserProfile: function(/*Function*/ callbackfn) {...}, setUserProfile: function(/*userProfile*/userProfile, /*Function*/ callbackfn) {...},

// Functions to manage attributes getAttribute: function(/*String*/ name) {...}, setAttribute: function(/*String*/ name, /*Object*/ value) {...}, removeAttribute: function(/*String*/ name) {...}, clearAttributes: function() {...},

// Reports the given error to the portal framework reportError: function(/*ibm.portal.portlet.Error*/ error) {...},});

Entry point: ibm.portal.portlet.PortletWindow Provides JS functions to access to the outlined functionality Defines useful constants for portlet modes, window states, response

status, errors Initialized with the portlet window identifier

STORY TITLE


XMLPortletRequest

ibm.portal.portlet.XMLPortletRequest Provides XMLHTTPRequest functionality for portlets

dojoportal.declare("ibm.portal.portlet.XMLPortletRequest", null, {

// Properties to read the ready state as well as register callback functions readyState: 0, /* int */ onreadystatechange: null, /*Function*/ onportletstateready: null, /* Function(ibm.portal.portlet.PortletState) */

// Properties to access the response body (either text or XML) responseText: null, /* String */ responseXML: null, /* Document */

// Properties to read the response status status: null, /* int */ statusText: null, /* String */

// Functions to open, send, and abort a synchronous or asynchronous request open: function( /*String*/ method, /*String*/ uri ) {...}, open: function( /*String*/ method, /*String*/ uri, /*boolean*/ async ) {...}, send: function( /*String or Document*/ data ) {...}, abort: function( ) {...},

// Functions to set request headers and read response headers setRequestHeader: function( /*String*/ header, /*String*/ value ) {...}, getAllResponseHeaders: function( ) {...}, getResponseHeader: function( /*String*/ header ) {...}

});

STORY TITLE


PortletState

ibm.portal.portlet.PortletState Allows to work with render parameters, portlet mode, window state

(navigational state) of the portlet window Changes are persisted when calling setPortletState() on the

PortletWindow object

dojoportal.declare("ibm.portal.portlet.PortletState", null, {

// Functions to read /write portlet mode getPortletMode:function() {...}, setPortletMode:function(/*ibm.portal.portlet.PortletMode*/ portletMode) {...},

// Functions to read /write portlet mode getWindowState:function() {...}, setWindowState:function(/*ibm.portal.portlet.WindowState*/windowState) {...},

// Functions to read render parameters getParameterNames: function() {...}, getParameterValue: function(/*String*/ name) {...}, getParameterValues: function(/*String*/ name) {...}, getParameterMap: function() {...},

// Functions to set /modify /remove render parameters setParameterValue: function(/*String*/ name, /*String*/ value) {...}, setParameterValues: function(/*String*/ name, /*String[]*/ values) {...}, setParameterMap: function(/*object[] {name: string, values: string[]}*/map, /*boolean*/replace) {...}, removeParameter: function(/*String*/name) {...}

});

STORY TITLE


PortletPreferences ibm.portal.portlet.PortletPreferences

Allows to work with configuration data (persistent state) of the portlet Distinguishes modifiable and read-only preferences (depends on portlet

mode) Changes are persisted when calling setPortletPreferences() on the

PortletWindow objectdojoportal.declare("ibm.portal.portlet.PortletPreferences", null, {

// Returns a preferences map (object[] {name: string, values: string[], readonly: boolean}) getMap: function() {...},

// Returns the names of the available preferences (String[]) getNames: function() {...},

// Functions to read preference values (String / String[]) getValue: function( /*String*/ key, /*String*/ default ) {...}, getValues: function( /*String*/ key, /*String[]*/ default ) {...},

// Checks whether the preference with the given name is a read-only preference isReadOnly: function( /*String*/ key ) {...},

// Functions to set /reset preference values reset: function ( /*String*/ key ) {...}, setValue: function ( /*String*/ key, /*String*/ value ) {...}, setValues: function( /*String*/ key, /*String[]*/ values ) {...},

// Function to clone the PortletPreferences object clone:function() {...}

});

STORY TITLE


Javascript Guidelines for Portlets

JavaScript in portlets is basically not different from any other webapp The only important point is that the same browser page is shared by

multiple portlets and the portal itself The same portlet can appear on a page multiple times!

Namespace page DOM elements and global JavaScript identifiers! Use RenderResponse.getNamespace() or the <portletAPI:namespace/> tag Returns a unique string for every portlet on a page

Offload JS code into separate files instead of including it in each page! Reduce page size and exploit the browser cache Exploit JS object structure to make namespacing easier

Avoid double initialization of common JS libraries! Check if library already initialized

Don’t replace global event handlers like page.onload! Somebody else may plug into them too Use attachEvent / addEvent (and, again, avoid double attaching!)

STORY TITLE


Summary

AJAX portlet development is possible More complex compared to a single servlet scenario (e.g. Google mail)

because multiple applications are aggregated on one page

For data retrieval use cases, WP 6.1 offers two approaches To connect to local data sources, JSR 286 resource requests should be used To connect to external data sources, the AJAX proxy should be used

The AJAX proxy allows security administrators to manage access to other domains

Whitelist approach: Only unlocked pages are accessible Handles cookie rewriting, header forwarding, connection management

Using the client-side portlet programming model, it is possble to implement AJAX portlets that behave consistently with server-side portlets

Even navigational state changes are possible Client-side APIs allow to conveniently use basic portlet contepts on the

client(portlet preferences, render parameters, portlet mode, window state etc.)

STORY TITLE


Session ID: D03

Session: Web 2.0, AJAX, and REST in WebSphere Portal 6.1

Presenter: Adam Cook

Please take a few minutes to fill out the session survey.

Thank you!


STORY TITLE


Additional Information and Resources

WebSphere Portal – IBM Site

http://www-3.ibm.com/software/genservers/portal/

WebSphere Portal Business Solutions Catalog:

http://catalog.lotus.com/wps/portal/portal

Websphere Portal Developer’s Zone

http://www-106.ibm.com/developerworks/websphere/zones/portal/

Product Documentation and WebSphere Portal Wiki

http://www-3.ibm.com/software/genservers/portal/library/

http://www-10.lotus.com/ldd/portalwiki.nsf

Education

http://www-3.ibm.com/software/genservers/portal/education/

WebSphere Portal 6.0 DemoNet

http://docs.dfw.ibm.com/wp6/?DDSPageRequest=/

STORY TITLE


Tools

AJAX Toolkit Framework (ATF) http://www.eclipse.org/atf/

Firebug: Firefox extension, DOM Inspector, JS Debugger & Console http://addons.mozilla.org/firefox/1843/

Fiddler: A free network traffic listener & proxy (works with IE and FF) http://www.fiddlertool.com

JSView: Firefox extension, easy access to external resources such as CSS and JS

http://addons.mozilla.org/firefox/2076/

LiveHTTPHeaders: Firefox extension, allows to look at requests http://livehttpheaders.mozdev.org/

STORY TITLE


Debugging Perspective

Views Threads Variables Source Outline

STORY TITLE


Debugging Perspective

Views Browser DOM Monitor

STORY TITLE


Debugging in Firefox using Firebug

Views: Browser, Source, Variables

STORY TITLE


Debugging in Firefox using Firebug Views XMLHttpRequest Monitor

STORY TITLE


© IBM Corporation 2008 All Rights Reserved.

The information contained in this publication is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this publication, it is provided AS IS without warranty of any kind, express or implied. In addition, this information is based on IBM’s current product plans and strategy, which are subject to change by IBM without notice. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this publication or any other materials. Nothing contained in this publication is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software.

References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in this presentation may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other results.

All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer.

IBM, the IBM logo, WebSphere, Lotus, Lotus Notes, Domino, Quickplace, Sametime, Workplace and Quickr are trademarks of International Business Machines Corporation in the United States, other countries, or both.

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both.

Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.

Other company, product, or service names may be trademarks or service marks of others.

All references to Renovations Inc. refer to a fictitious company and are used for illustration purposes only.

© 2008 ibm session id: d03 title: web 2.0, ajax, and rest for wp 6.1 speaker: adam cook, ibm...

Documents

portal url

portal data access

ajax portlets ajax support

ajax applications client

agile ajax

portal models content

information web

new web