you mean have a portlet linking to another portlet ?

Hi,

There isn't any way as part of the JSR-168 portlet spec, which the JBoss Portal is implemented against. However, it's so useful that the JBoss guys may have implemented an extension specific to their APIs - but I don't know what.

The way we did it (back in the days of the Alpha version) was to construct JBoss portal specific URLs. E.g. the way JBoss portal references portlets is through a defined URL format, so if you construct the URLs appropriately you can get other portlets to maximise:

http://localhost:8080/portal/index.html?ctrl:id=window.default.CMSPortletWindow&ctrl:type=nav&ctrl:windowstate=maximized

http://localhost:8080/portal/index.html?ctrl:id=window.default.UserPortletWindow1&ctrl:type=render&ctrl:windowstate=maximized&op=showRegister

I think we are going to do something for 2.0.1 or 2.2.

ok, I am asking because portlet communication means a lot of different things for people and the one I said is the most requested.

what is the scope of event delivery ? per user ? could you describe it ?

For reference, here's a response from the end of last year with respect to JSR-168:

http://mail-archives.apache.org/mod_mbox/portals-pluto-dev/200411.mbox/%3c4194D221.3090604@apache.org%3ehe.org/mod_mbox/portals-pluto-dev/200411.mbox/%3c4194D221.3090604@apache.org%3e

I think what you're looking for could be addressed in the next version of the standard. Meanwhile, most portals have their own different ways of doing this.

Cheers
Phh.

I ran into this same limitation in the JSR-168 spec. the functionality was important enough to me that i found a workaround for it, and one that is not specific to JBP. If you have two portlets in a portlet-app then they share application scope session attributes. I have a navigation portlet in the left column, and a view portlet as the main content. My navigation consists of ActionURL links, sending a param for which page to view. The processAction stores the page to view in the session attribute. When each of the portlets go thru their doView rendering, the session attribute is set and they display based on that. So the navigation portlet can show which page the user is on, and the main content portlet can display the page that was chosen.

It's not the most elegant approach, but it's working so far. I would also like for the spec to expand to impliment some form of interportlet communication, but for now i'll just use session attributes. ... .joe

There is a another specification that defines a contract between portal consumer and portlet consumer for remote portlets utilizing soap - WSRP (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp). Second version of this specification that have been discussed now introduces event handling mechanism that will allow consumer to distribute events to any portlet and any portlet to generate events as a result of perform action or event distribution call. My suggestion would be to use this specification as a guide line for even support architecture.

WSRP 2.0 will be implemented in JBoss Portal in the next version - 2.2. Our Novell team will be handling the ins and outs, since I stubbornly refuse to read the WSRP spec. ;-)

There is no public draft of WSRP 2.0 specification. You will have to join WSRP TC group.

Hi. There may be no standard, but this code works just fine for us. Define a class to which all portlets have access and change it according to your needs:


import java.util.Hashtable;

public class InterPortletCommManager {

private static InterPortletCommManager thisMgr = null;
private Hashtable something;

private InterPortletCommManager() {
try {
something = new Hashtable();
// do any initialization of local variables here
}
catch (Exception ex) {

}
}

public static InterPortletCommManager getInstance() {
if (thisMgr == null) {
thisMgr = new InterPortletCommManager();
}
return thisMgr;
}

public Object getObject(String portletId) {
// retrieve an Object by using a portlet ID
return something.get(portletId);
}

public void setObject(String portletId, Object someObject) {
// use the ID of a portlet as a key for the object to be stored
something.put(portletId, someObject);
}

}

with InterPortletCommManager.getInstance() all portlets have access to the Vector "something". Of course you can create other methods and other objects to use amongst all portlets.

Hope it helps. Regards, dj