02-10-06 10:54 PM
Many have asked about implementing Ajax with WebSphere Portal. Following is
some useful information informally provided by development outlining approac
hes 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 th
e 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 generati
ng 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 tar
get of your XMLHttpRequest, and then update the dom with the new data. Bene
fit of this way over the iframe, is if the back-end can generate the data pa
yload as straight xml, to m
inimize data transfer
3)if you bundle the servlet and portlet in the same war file, and the portle
t is JSR168 based, then you can use the application scope support when putt
ing 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 informat
ion.
4)you could use the public urlgenerationtag to generate a link back to the p
ortlet in maximized mode, then have your view code mark where the updated da
ta is, and have your Ajax JavaScript just parse that subpart of the markup b
ack and update the DOM, and
throw away the extra markup. Several customers are doing this, since they d
idn'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 p
ortlet in solo mode, with newwindow=true, this would generate only the portl
et 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 identif
iers so that down on the client in can strip out all relevant parts. One n
ice 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 gener
ated. So in theory, you could have the JavaScript not only update the singl
e portlet but other portle
t's markup that was changed. For example, using the ordering portlet wirin
g samples, if i change an order id in one portlet you could cause the marku
p 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 gotch
a's to watch out for, including session time-outs, cacheablity, security set
tings, interportlet communication, etc.... Especially if your trying to man
age state type of informati
on.
[ Post a follow-up to this message ]
| 
