WebSphere Portal Server - Question regarding the communication between portlets

Author

Question regarding the communication between portlets

2005-07-20, 2:49 am

Hi all,

I am new to IBM portlet technology. I am wondering if it's possible to invoke an action on a portlet without affecting the other portlets. As what I have been observed, all the portlets in the same portal page will be refreshed once one of the portlet
inside the portal page that requested some actions(or refreshed).

One more example that is, I have two portlets(two forms) in the same portal page. I want to submit the form in the first portlet without affecting the values of the textboxs, dropdown box in the other portlet. Is that possible? Are there any workarou
nds ?

I really want to know about this technical fact so that i can go further about the portlet development.

Thanks

AK

2005-07-21, 6:03 pm

Hi AK,

You have it right. I like to call it Loss of Data. If a user inputs values into a portlet and does not submit the values, the values will be lost if there are any screen refreshes. You have to come up with a Kludge to fix the problem. The Administratio
n portlets basically submit on every user action so values are not lost. This leads to a pretty ugly and undynamic design.

You have taken the first step and have seen one of the shortcommings of the portal environment. There are a myriad of options to fix the problem, none of them great.

jruske

2005-07-21, 6:03 pm

As Claverty noted, what you are describing is intentional behaviour. First - the entire portal page is refreshed on any interaction with a portlet so all the other portlets will returnt o initial conditions or act on any values made available due to a si
ngle portlet's action.

An example of a work around would be the use of iFrames in portlets - and that's a nasty kludge since anything in an iFrame is unavailable to the context of the rest of the portal page. And you still usually lose the data (since the iFrame URL is reset t
o the intial target if the portlet is reloaded).

Second - values entered into other portlets, the state of the other portlets (view vs edit), the actual content of other portlets (search results following a form submit), are lost unless you capture every click or keystroke with something like Javascript
and stuff it someplace longer lived. And that's a really nasty kludge.

So typicallly successful implementations adopt a specific kind of flow. The first page is dashboards with some form portlets to drive the user into work activities. Work Activity Pages are either maximized portlets looking at a full application or portl
et applications which have click to action or similar functionality enabled (e.g. they share javabeans) that preserves state of individual portlet views. Content portlets may be on these pages but they are kept to a minimum or launch a new browser focuse
d on content (e.g. the user help is launched in a seperate browser so the user can follow along as they do the work activity rather than lose the help as soon as they click on the first step).

So there are some challenges technically as well as for business designers.

-J Ruske

2005-07-21, 6:03 pm

Great post jruske.

We have implemented something similar to the comment you made about controlling the flow. This is the best solution I have come across so far.

"So typicallly successful implementations adopt a specific kind of flow. The first page is dashboards with some form portlets to drive the user into work activities. Work Activity Pages are either maximized portlets looking at a full application or portle
t applications which have click to action or similar functionality enabled (e.g. they share javabeans) that preserves state of individual portlet views. Content portlets may be on these pages but they are kept to a minimum or launch a new browser focused
on content (e.g. the user help is launched in a seperate browser so the user can follow along as they do the work activity rather than lose the help as soon as they click on the first step)."