How to determine what content other portlets on the page are displaying?

[12年前 に Phoenix Zerin によって更新されました。]

I have a few scenarios where I need a portlet to be able to "collect" the content that is being displayed by other portlets on the same page.

For example, a Related Content portlet has to know what content the user is currently looking at in order to search for content that is related.

What are some ways that a portlet might go about collecting this information?

[12年前 に Bijan Vakili によって更新されました。]

Use public render parameters and events to achieve this. Google these to find out more.

Let us know should you have further questions.

[12年前 に Phoenix Zerin によって更新されました。]

Thanks Bijan. I did leave my question a little vague, but I was just trying to avoid The XY Problem.

I thought about going the event route, but we are also leveraging a number of built-in portlets (e.g., Web Content Display) which I wasn't keen on "extending" to add the event firing (unless I did that in a JSP hook, but that just feels wrong).

Are there any other approaches one might take to determining the Web Content that appears on other portlets on the page, or is there a way to make built-in portlets or services fire an event when they access Journal Articles (preferably without using EXT)?

[12年前 に Stian Sigvartsen によって更新されました。]

I too would like to know if this is possible.
I have not come across any substantial use of JSR-286 eventing in Liferay out of the box portlets.

However, our portal strategy relies heavily on component based design, and this is made possible through our IPC strategy. Unfortunately, at present it doesn't extend to include the out of the box portlets.

At present, I think the best approach to "upgrading" the out of the box portlets to publish events would be to create a portlet filter implementing ActionFilter and then add logic to setEvent() based on your interpretation of what the action request represents.

And that's where the solution becomes a bit difficult to manage... you need to have an understanding of how the out of the box portlets generate action URLs.

Also, there doesn't seem to be an obvious way to determine what state changes happened as a consequence of the user's action request. You might need to implement a model listener for that and somehow correlate changes in the model(s) with the action request. I do not know how that could be done at this stage, but I have yet to investigate it in any great detail.

However, the approach makes it relatively easy to detect the user's *intention*, so may be useful in some ways.