|
Home > Archive > WebSphere Portal Server > March 2006 > Techniques for implementing Ajax in WebSphere Portal applications
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Techniques for implementing Ajax in WebSphere Portal applications
|
|
|
| Many have asked about implementing Ajax with WebSphere Portal. Following is some useful information informally provided by development outlining approaches to consider.
There are many portal customers that are using ajax/iframes/applets today in their portals. They usually fall in one of these categories:
Note: you can use hidden iframes instead of xmlhttpRequest too for any of the below statements. They are interchangeable for the most part.
1)implement a simple servlet or .jsp that retrieves the back-end, and bundle it with your portlet. Then in the portlet, use the normal tag for generating a portlet url to a gif file, but instead point to your servlet/jsp. like :
in your .jsp for your portlet have it just render:
<IFRAME src='<portletAPI:encodeURI path="myservlets/foo.jsp" />' />
Then have your JavaScript parse what is in the markup and update the DOM
2)you could generate this using Ajax, just use that url as in #1, as the target of your XMLHttpRequest, and then update the dom with the new data. Benefit of this way over the iframe, is if the back-end can generate the data payload as straight xml, to m
inimize data transfer
3)if you bundle the servlet and portlet in the same war file, and the portlet is JSR168 based, then you can use the application scope support when putting things in the session. This lets the portlet and servlet share the same session, so anything you d
o in either the portlet or servlet can update the same stored state information.
4)you could use the public urlgenerationtag to generate a link back to the portlet in maximized mode, then have your view code mark where the updated data is, and have your Ajax JavaScript just parse that subpart of the markup back and update the DOM, and
throw away the extra markup. Several customers are doing this, since they didn't want to programming models. So this lets them just write portlets as normal
5)you could use the public urlgenerationtag to generate a link back to the portlet in solo mode, with newwindow=true, this would generate only the portlet markup and no theme
6)you use normal link and action urls and add parameter to identify this as a request coming from AJAX call. Then the portlet can add additional identifiers so that down on the client in can strip out all relevant parts. One nice feature of this way, is
when its an action, there could be portlet wires and portlet events between portlets occurring, and all those portlets will be updated, and markup generated. So in theory, you could have the JavaScript not only update the single portlet but other portle
t's markup that was changed. For example, using the ordering portlet wiring samples, if i change an order id in one portlet you could cause the markup in another portlet to be updated as a result, without ever seeing the page flash.
Finally, you can also use Ajax/iframes/applets in themes/skins. Just bundle your servlets in with the theme and skins, and use normal taglibs to create the urls to your servlet
You do have to be careful on how you use Ajax/iframes. There are many gotcha's to watch out for, including session time-outs, cacheablity, security settings, interportlet communication, etc.... Especially if your trying to manage state type of informati
on.
| |
|
| This post doesn't seem to render correctly for me!
|
|
|
|
|