1 / 53

Stefan Behl, WebSphere Portal Web 2.0 Development Engineer

Session Number: D03 Developing AJAX-enabled Portlets in WebSphere Portal 6: Concepts, Patterns and Best Practices. Stefan Behl, WebSphere Portal Web 2.0 Development Engineer. Disclaimer.

druce
Télécharger la présentation

Stefan Behl, WebSphere Portal Web 2.0 Development Engineer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Session Number:D03Developing AJAX-enabled Portlets in WebSphere Portal 6:Concepts, Patterns and BestPractices Stefan Behl, WebSphere Portal Web 2.0 Development Engineer

  2. Disclaimer The following includes material that isdirectional in nature and does not imply anyproduct plan commitment on the part of IBM. Screenshots in this presentation are fromprototypes and likely to change significantlyby the time products are released.

  3. Agenda • Introducing AJAX and related technologies • AJAX • REST • Browser features • Frameworks • Using AJAX in a portal environment • Challenges • Client-side aggregation • Developing AJAX portlets • Developing AJAX portlets for WebSphere Portal 6.0 • Evolution of portlet standards: AJAX support in JSR 286 and WSRP 2.0 • AJAX support in WebSphere Portal 6.1 • Summary

  4. Part IIntroducing AJAXand related technologies

  5. What is AJAX ? • AJAX is the acronym for Asynchronous JavaScript and XML • The purpose is to create more dynamic and responsive web pages • It is a pattern where a page view displayed in a web browser retrieves data or markup fragments from a service and refreshes just a part of the page Server Browser Markup (HTML) Request Services Data (XML)

  6. What is AJAX ? (cont.) • AJAX is NOT hype • It is very real and very useful for highly interactive applications • AJAX enables major improvements in responsiveness and performance • Examples: Yahoo! Mail, Google Maps, live.com, etc. • AJAX is not only appealing to cool web sites but also to enterprise customers • AJAX is based on existing technologies and standards • HTML, Javascript & DOM, REST, XML / XSLT, ATOM / APP, Web Services • Not always XML – other data formats such as JSON, HTML can be used as well • Not always asynchronous • AJAX is not trivial • Without tools, it requires requires deep and broad skills in web development • But: the benefits to be gained can be huge compared to classic web applications

  7. AJAX – Advantages and Challenges Challenges • Currently there is no AJAX standard; browsers behave differently and have different APIs • Higher complexity: Developers need to deal with a variety of technologies, like XML parsing, DOM manipulation, JavaScript and browser specific issues • Bypasses standard browser paradigms (e.g. back button, reload); requires extra effort to get these paradigms working again • Complex web pages with different topics typically have inter-dependencies that have to be managed Advantages • Improved UI response times and better usability due to asynchronous data transfer and direct markup updates on the client • Better scalability and improved failure safety due to workload distribution and decoupling of services • Reduced server load due to client-side processing and rendering • Extremely helpful in complex web pages aggregating many different fragments  allows to update single page fragments

  8. What is REST? • REST is the acronym for Representational State Transfer • It is the architectural model on which the World Wide Web is based • Principles of REST • Resource-centric approach • All relevant resources are addressable via URIs • Stateless prototcol based on HTTP GET, POST, PUT, and DELETE • Content type negotiation allows retrieving alternative representations from same URI • REST style services • Easy to access from code running in web browsers, any other client or servers very popular in the context of AJAX • Can take full advantage of the WWW caching infrastructure • Can serve multiple representations of the same resource • More info: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

  9. Frameworks • WebSphere Portlet Factory 6.0 • Incremental Search Builder • Type-ahead field: provides a drop-down list of suggestions to users as they type • Asynchronous Client Loader Builder • Allows a portlet to update without refreshing the entire Portal page • Any action can easily be exposed as a REST-style service • Especially useful when combined with back-end integration builders • DoJo • Javascript framework (Abstraction Layer to allow browser independence) • Many widgets available • Rich Javascript framework that can be used within portlets • AJAX and JSF combined: JSF Widget Set (JWL) • Extends the JSF server-side programming model to the client • Adds visual components to the AJAX approach • Provides client-side XML data model with updates on client side • Full visual tooling via Rational Application Developer (RAD) • Recommended if you want to use the AJAX pattern in your portlets

  10. WebSphere Portlet Factory: AJAX Builders In Action Client-side Data access via REST service Type-ahead Partial-page refresh

  11. Part IIUsing AJAX in a Portal EnvironmentWhy AJAX has special challenges in a portal environmentClient-side aggregation

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

  13. Bookmarkability, Back Button, Multiple Windows

  14. Crawlability and Caching

  15. WAR WAR WAR WAR WAR Portlet Portlet Portlet WAR WAR Portlet Without AJAX – The classic portal • Each request goes to the main portal servlet • Each interaction causes a full page refresh • Even if the portlet does not communicate with other portlets Portal Server Browser Portal WAR Click Request Servlet Response

  16. Using AJAX in Portals • A portal page is normally composed of lots of fragments • Header, footer • Navigation • Toolbars • Portlets • UI widgets inside the portlets • User interaction will typically only affect a single fragment • Lots of situations where applying AJAX makes sense!

  17. WAR WAR WAR WAR WAR Portlet Portlet Portlet WAR WAR Portlet XHR Click XHR AJAX flavor 1 – Client-side Aggregation • Client-side aggregation • Browser-side page aggregation, navigation, and customization delivered with WebSphere Portal 6.1 • Implemented using AJAX, XML, Dojo, and JavaScript • AJAX handling implemented entirely by the portal • AJAX-enabled portal refreshes only those portlets affected by the user interaction Portal Server Browser Portal WAR Client-side aggregation Servlet JS Handler Property Broker, Shared session etc.c

  18. Client-side Aggregation (cont.) • 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

  19. Part IIIDeveloping AJAX portletsHow to develop AJAX portletsEvolution of portlet standardsAJAX support in WebSphere Portal 6.1

  20. Using AJAX inside of portlets Two 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

  21. WAR WAR WAR WAR WAR Portlet Portlet Portlet JS WAR WAR Portlet AJAX flavor 2Portlet connecting to an external data source • AJAX-enabled portlet only reloads affected content • Content source is outside the portal • Can be implemented using JSR 168 • Possible in WebSphere Portal 6.0 Portal Server Portal WAR Servlet Browser Click External Server (e.g. Mail Server) XHR e.g. XML ContentProducer Servlet

  22. Portlet connecting to an external data source • Portlet is doing the AJAX handling • Works on any standards-compliant portal • Portlets usually need AJAX Javascript libraries – watch out for conflicts! • AJAX call cannot use portlet APIs or affect the portlet state • Can be used to update backend data and clean server-side caches if necessary • View changes are typically lost in case of a full page refresh • Useful if the portlet is displaying content from a different source anyway • E.g. from mail server • Improves performance by avoiding to route calls through the portal server • Take care of same-origin policy! • Common pattern for closer portlet integration is to use a servlet that is packaged within the portlet WAR file • See next slides

  23. AJAX Proxy • Today's browsers restrict the functionality of asynchronous requests to the same domain because of security reasons • Example: Your portlet is served from www.mycompany.com but your AJAX application tries to load a feed from cnn.com. This would be blocked from the browser • AJAX proxy: Central security component to manage access to other domains Domain A AJAX Proxy Browser HTTP GET Domain A Server Trusted sites HTML Page Domain B HTTP GET Domain B AJAX Portlet Server

  24. WAR WAR WAR Portlet Portlet JS WAR WAR Portlet AJAX flavor 3Using a servlet packaged with the portlet • Portlet WAR contains one portlet and one servlet (might act as a proxy) • Portlet is embedded into markup like any other portlet • Portlet is able to transfer some data through the HTTPSessionto the servlet using the APPLICATION Scope • request.getPortletSession().setAttribute("myName", someValue, PortletSession.APPLICATION_SCOPE); • The portlet markup contains Javascript and a URL pointing back to the servlet • Servlet is directly accessed through Javascript in portlet markup • Possible in WebSphere Portal 6.0 Portal Server Portal WAR WAR Browser WAR Portlet Servlet Click HTTPSession Servlet e.g. XML /HTML External Server (e.g. Mail Server)

  25. Implementation hints • Portlet Implementation • Encode portlet context path into markup (needed to generate URL to servlet on the client) • On the client, submit XMLHttpRequests using URLs pointing to the servlet • Append the URL as a request parameter • Servlet Implementation • Returns content either directly or from any given URL passed along as a request parameter • Servlet could also just access any backend like SAP or JCR to return content, or use any JSP to create new markup function loadRemoteDataThroughProxy(namespace) { contextpath = document.getElementById(namespace+"_contextpath").getAttribute("name"); loadMyXML(contextpath+ "/ajaxServlet?url=http://rss.cnn.com/rss/cnn_topstories.rss", replaceDom, namespace); } public class AjaxServlet extends GenericServlet { public void service(ServletRequest request, ServletResponse response) throws ServletException, IOException { String url = request.getParameter("url"); if (url != null) { URL _url = new URL(url); writeContent(_url, response.getWriter()); } } private void writeContent(URL url, Writer writer) throws IOException { URLConnection conn = url.openConnection(); ...

  26. 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 will support JSR 286 and WSRP 2.0!

  27. Resource request • 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

  28. JS WAR WAR WAR WAR WAR Portlet Portlet Portlet WAR WAR Portlet AJAX flavor 4Partial updates using resource request (JSR 286) • 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 Server Browser Portal WAR Click XHR Servlet XML /HTML

  29. AJAX using the resource request • 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.

  30. JS WAR WAR WAR WAR WAR Portlet Portlet Portlet WAR WAR Portlet AJAX flavor 5Portlets requests (JSR 286) via XMLPortletRequest • AJAX-enabled portlet reloads affected content using a portlet request • AJAX call handled by the portlet and the portal • Can be implemented using JSR 286 and JS Portlet API provided by WebSphere Portal 6.1 • Solution which even handles navigational state and intercommunication properly • Possible in WebSphere Portal 6.1 Portal Server Browser Portal WAR Click Client-side portal framework Request XMLPortletReq Servlet Property Broker, Shared session etc.c XML /HTML Request 2

  31. Full AJAX support in portlets • Requires coordination between portal and portlet • Portal provides an AJAX library for calls by the portlets • Client-side navigational state can be updated • Changes are retained even if the user clicks outside the current portlet • Full functionality is available on the server • Can write to preferences, send events, etc. • Need action and render phase on the server during the AJAX call • Why is the XMLPortletRequest not part of JSR 286? • Too hard to agree on a proposal, wait for experience from the field with vendor-specific extensions • Several major vendors (including IBM) will propose a common Javascript extension API

  32. WAR WAR WAR WAR WAR Portlet Portlet Portlet WAR WAR Portlet AJAX flavor 6: Portlets using the JS Portlet API The full-blown solution... Portal Server Browser Portal WAR Client-side portalframework Request Servlet Click Portlet API XMLPortletRequest XML /HTML JS Preferences Request Pref. feed Nav. State User Profile REST Preferences Request User Prof. feed User Profile DB Other

  33. JS Portlet API • WebSphere Portal 6.1 • Client-side portlet programming model • Convenience JavaScript APIs simplifying portlet development • Client-side equivalent to the Java Portlet API • Coordinates AJAX calls with the portal • Consistent behavior after a full page refresh • Navigational state changes • Implemented using DOJO • Might still change slightly • Functionality • XMLPortletRequest • Read & write navigational state(mode, window state, render parameters) • Read & write portlet preferences • Read user profile information • Read & write client-side attributes • Report errors to the portal framework

  34. JS Portlet API – PortletWindow • 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, error types • Initializes with the portlet window identifier 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 navigational state (portlet mode, window state, render parameters) newRenderURL: function(/*PortletState*/ state) {...}, // 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) {...}, });

  35. JS Portlet API – 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 ) {...} });

  36. JS Portlet API – 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) {...} });

  37. JS Portlet API – 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 object dojoportal.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() {...} });

  38. Implementing a portlet using the JS Portlet API • Proposed design pattern • Create the PortletWindow object in your JSPs • Render the initial view in your JSPs • Implement a JS class representing the portlet (use a separate JS file) • Pass in namespace and PortletWindow object via constructor • Namespace is needed for dynamic DOM updates (to address DOM nodes) • PortletWindow is needed to implement business logic Portlet WAR JSP JSP JS File instantiate Inline script JSP Portletclass <b>...</b> <div> <a onclick=...> </a> <form ...> </div>

  39. Sample JSP <%@ page session="false" %> <%@ page import="..." %> <%@ taglib uri="http://java.sun.com/portlet" prefix="portletAPI" %> <%@ taglib uri="http://www.ibm.com/xmlns/prod/websphere/portal/v6.1/portlet-client-model" prefix="portlet-client-model" %> <portletAPI:defineObjects/> <!–- Load the JS Portlet API --> <portlet-client-model:init> <portlet-client-model:require module="ibm.portal.portlet.*"/> </portlet-client-model:init> <!–- Initial markup --> <b>Add new list item</b> <!–- Call list portlet’s addListItem function --> <form onsubmit="listPortlet<%=portletWindowID%>.addListItem(this.newItem.value); return false;"> <input name="newItem" type="text"></input> <input type="Submit" value="Add list item"></input> </form><form > </form> <div id="list<%=portletWindowID%>"> <!–- Display dynamic list here --> </div> <script> var portletWindow<%=portletWindowID%> = new ibm.portal.portlet.PortletWindow("<%=portletWindowID%>"); var listPortlet<%=portletWindowID%> = new ListPortlet("<%=portletWindowID%>", portletWindow<%=portletWindowID%>); // add portlet object to window (needed for callback functions!) portletWindow<%=portletWindowID%>.setAttribute("portlet", listPortlet<%=portletWindowID%>); // load preferences to display initial list portletWindow<%=portletWindowID%>.getPortletPreferences( listPortlet<%=portletWindowID%>.handleLoadPortletPreferences) </script> Important: Namespace page DOM elements! Important: Namespace JS identifiers!

  40. if ( typeof( ListPortlet ) == "undefined" ) { var ListPortlet = function (_namespace, _portletWindow) { this.namespace = _namespace; this.portletWindow = _portletWindow; } ListPortlet.prototype = { handleLoadPortletPreferences: function(portletWindow, status, prefs) { if (status==ibm.portal.portlet.PortletWindow.STATUS_OK) { portletWindow.setAttribute("preferences", prefs); portletWindow.getAttribute("portlet").renderList(); } else { portletWindow.reportError(new ibm.portal.portlet.Error( ibm.portal.portlet.Error.ERROR, "Error loading preferences.", "Status code: "+status)); } }, handleSavePortletPreferences: function(portletWindow, status, prefs) { if (status==ibm.portal.portlet.PortletWindow.STATUS_OK) { portletWindow.setAttribute("preferences", prefs); } else { // error handling; report error and then invoke renderList function to render previous list ... } }, renderList: function() { var prefs = this.portletWindow.getAttribute("preferences"); var listElems = prefs.getValues("list", null); // append list elements to DOM var listRoot = document.getElementById("list" + this.namespace); ... }, addListItem: function(newItem) { // update DOM ... // save preferences var prefs = this.portletWindow.getAttribute("preferences"); var listElems = prefs.getValues("list", null); listElems.push(newItem); prefs.setValues("list", listElems); // setPortletPreferences will return immediately (asynchronous request) this.portletWindow.setPortletPreferences(prefs, handleSavePortletPreferences); } } Sample JS portlet Important: Do not use „this“ within callback functions! Callback functions are executed in a different context.

  41. Javascript in 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 apprear 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!)

  42. Summary • AJAX within a Portal environment is possible • It is more complex compared to a single servlet scenario (e.g. Google mail) because of its nature of aggregating multiple fragments on one page • Using a framework helps to circumvent most of the Web capabilities problems • Special support in a portlet is sometimes necessary (e.g. Crawlability) • For WebSphere Portal 6.0 it might be worth to not leverage Navigational State AJAX flavor 3 recommended (Servlet packaged with portlet) • With WebSphere Portal 6.1 it will be possible to implement AJAX portlets behaving consistently with server-side portlets using JSR 286 concepts as well as the offered JS Portlet API AJAX flavor 6 recommended (Portlet using the JS Portlet API) • JS Portlet API allows to conveniently use basic portlet concepts on the client (render parameters, preferences, user profile etc.)

  43. Additional Information and Resources • AJAX Toolkit Framework (ATF) • http://www.eclipse.org/atf/ • Firebug – Firefox extension, DOM Inspector & Modifier, JS Debugger & Console • http://addons.mozilla.org/firefox/1843/ • Fiddler – 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/ • Websphere Portal Business Solutions Catalog: • http://catalog.lotus.com/wps/portal/portal • Webspere Portal Product Information: • http://www-306.ibm.com/software/genservers/porta • WebSphere Portal Information Center Documentation: • http://www.ibm.com/developerworks/websphere/zones/portal/proddoc.html

  44. Backup Slides

  45. AJAX Proxy • Today's browsers restrict the functionality of asynchronous requests to the same domain because of security reasons • Example: Your portlet is served from www.mycompany.com but your AJAX application tries to load a feed from cnn.com. This would be blocked from the browser • AJAX proxy: Central security component to manage access to other domains Domain A AJAX Proxy Browser HTTP GET Domain A Server Trusted sites HTML Page Domain B HTTP GET Domain B AJAX Portlet Server

  46. Tools

  47. Tools • AJAX Toolkit Framework (ATF) • http://www.eclipse.org/atf/ • Firebug – Firefox extension, DOM Inspector & Modifier, JS Debugger & Console • http://addons.mozilla.org/firefox/1843/ • Fiddler – A 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/

  48. Tools Debugging Demo Using Eclipse with ATF

  49. Debugging Perspective • Views • Threads • Variables • Source • Outline

  50. Debugging Perspective • Views • Browser • DOM • Monitor

More Related