You can't. Usually it would be a bad practice. Why do you need this ?
Well, IBM WPS 6.1 provides that..infact they have it right from the 5.0 version of WPS. It would have been added for a reason. Is it not required in JBoss i mean may be for the sake of being in the competitive space?
Please, the fact that any vendor does it doesn't mean anything.
Providing this gives a false sense of portal portability, which in the end allows for vendor lock-in.
Events are a powerful but dangerous feature "with great power comes great responsibility". This is why I asked for the usecase as often developers tend to use this mechanism to replace a mechanism like JMS that guarantees delivery (and portlet events don't) or other things for which portlet events aren't designed for.
I encounter the same restriction. My use case is that I'm building an application composed by a few modules (each modules comes as a portlet package in a war).
I use some page spaces in order to compose different views of my application (base on the role or the application context (summary page, detail page)).
I can pass from one page to another but I need to instruct the target page (in fact the target portlets) for some params. So I build a sort of session Handler (DB storage) on top of synchronized by the sessionID.
I don't like that to much (should not work on distributed applications), but I don't know how to do that differently. I regret the lake of a Portal Scope variable.
Yes, cross-page wiring will be required when there are different page views to be provided to user based on certain conditions. Is it not a limitation in JBoss then?
Question of language : It is not a limitation... It is a non addressed feature.
But I agree with you, JBP lake of this sort of feature.
JSR 286 events are meant for UI events. I'd argue that, and this is why we haven't implemented cross-page wiring, wanting to change things across several pages is not in the realm of UI anymore (since you won't be able to see everything at the same time), rather it's a business domain issue where, as Thomas pointed out, better but also more appropriate solutions exist for reliable business domain messaging across portlets.
That said, you are welcome to open a JIRA feature request for such a feature and make a case for it. :)
I argue that it can be in the realm of UI. In my setup I have 2 physical monitors and a browser window is shown on each monitor. I would like to display different portal pages in these browser windows and have the portlets loaded on these pages to interoperate.
In this setup I am perfectly able to see "everything" at the same time.
Fair enough. Like I said, feel free to open a JIRA for it if you think this is something that is really missing and for which a valid set of use cases can be identified.
We always consider new features if they make sense but we won't implement something just because someone else supports it. :)
to clarify this issue to me:
According to JSR 286 a portlet will not react upon a Portlet-Event, if it is on a page, that is not the current viewed page, right?
This leads me to another question:
As I understood, according to JSR 168 a portlet on a page, that is not the current viewed page, does not even take part in the portlet-lifecycle, i.e. the renderResponse- and processAction-methods won't be invoked. Is this correct?
That sounds about right.
To me, what is not set in stone is, whether you can have more that one currently viewed page or not.
In a dual monitor setup this is easily achieved, and it would make sense for all portlets on the two pages to take part in the event distribution.
I have a confusison here. We are talking about pages, but does the 286 spec even know anything about the pages. I mean creation of pages and aggregation of portlets on the pages is implemntation specific. A portlet cannot know of the page in which it is placed. Is this understanding incorrect?
Dorothy you are right, the spec doesn't defines this as it doesn't own the notion of page.
Hilmer's scenario is an interesting one, if the content on the other page updates itself with something like Ajax (otherwise the other page wouldn't get refreshed).
Dorothy, you are also right that using the portlet API a portlet cannot know on which page it is, but most portal (such as JBoss Portal) offers an API to give you access to that info.
Yeah, but as chris had suggested, I want to open a jira for the addition of the cross-page wiring feature. Need advise on how to do that. Pl. suggest