how to call Portlet action method from another Portlet?

[Tanaji M. Londhe, geändert vor 11 Jahren.]

I am having Portlet-A & Portlet-B with following action methods
Portlet A
public void methodA(ActionRequest actionRequest,
ActionResponse actionResponse) throws IOException, PortletException {
System.out.println("Portlet A action method get called!");
}

Portlet B
public void methodB(ActionRequest actionRequest,
ActionResponse actionResponse) throws IOException, PortletException {
System.out.println("Portlet B action method get called!");
}
Is it possible to call methodB into a Portlet-A class?

[Gnaniyar Zubair, geändert vor 11 Jahren.]

Please try this to call another portlet's action from current portlet jsp :

<liferay-portlet:actionurl var="actionURL" portletname="portlet2_WAR_<instanceId>"></liferay-portlet:actionurl>

- Gnaniyar Zubair

[Tanaji M. Londhe, geändert vor 11 Jahren.]

Hi Gnaniyar,
Thanks for reply.
But I want call action method into my portlet class not on the jsp page.

[David H Nebinger, geändert vor 11 Jahren.]

Tanaji M. Londhe:

But I want call action method into my portlet class not on the jsp page.

Not going to happen. In this kind of scenario (shared logic), you can use SB to create a service method, you can refactor the shared code into a jar that is loaded by both portlets, but you cannot just invoke some method on some instantiated object that is probably loaded in some other class loader.

[Tanaji M. Londhe, geändert vor 11 Jahren.]

Hi David,
I get some blog post for this
http://www.opensource-techblog.com/2012/12/call-portlet-action-method-from-another.html

[David H Nebinger, geändert vor 11 Jahren.]

Wow, that's a lot of hacking and a lot of assumptions being made that allow that to work...

For example, if the administrator removed the factorial portlet, your multiplication portlet is immediately broken. You're also assuming that permissions allow the user to be able to see both portlets (which may or may not be true in a typical use case), the administrator may have put the portlets in different groups (thus preventing you from doing the lookups in the first place), ...

If someone asked me to implement this w/ the understanding that the two portlets should be in separate WAR file deployments, I'd start w/ the factorial guy and actually add a service builder to him. He'd have a single entity, factorial, with no columns (thus no database requirements). SB will generate the FactorialLocalServiceImpl class, to which I'd add the method "public int getFactorial(int value)" w/ my factorial function, then I'd rerun SB again.

The code for the factorial action handler would then use FactorialLocalServiceUtil.getFactorial() to do the work of the calculation, and the factorial portlet JSP pages are just retrieving the user value (for the calculation) and displaying the result coming from the getFactorial() method. Not too much of a difference between what your factorial portlet is currently doing, just segregating the code a little bit to make it reusable.

Now for the Multiplication portlet. In this portlet I go to the liferay-plugin-package.properties file and I add a required deployment context value for the factorial guy in the Liferay IDE. The IDE will pull over the service jar automatically. Now, the link for the "get factorial here" just ends up being a link into your own JSP page in the multiplication portlet. In the action handler here, this code also calls FactorialLocalServiceUtil.getFactorial() to handle the calculation, and the JSP page displays the calculated value.

Now, all of the issues I pointed out above are gone. There is no dependency on having the factorial portlet placed on a page. There is no dependency on permissions the user may have to the multiplication portlet also being able to see and use the factorial portlet. There is no dependency on having the portlets as part of the same group. The only dependency my process adds is that the factorial portlet must be deployed in Liferay (deployed but not actually placed on a page) before the multiplication portlet would be available.

So my only comment is yes, you've found a solution, but it is a solution that works in the very narrowest of circumstances and breaks should an administrator (and not a developer) makes a change in the portal.

In the end, I would never ever suggest anyone follow your model for invoking a 'shared' chunk of code the way you have. And frankly I wouldn't even want one portlet changing the page the user is on just so they can see a result on a separate page, but that's just me.

[Tanaji M. Londhe, geändert vor 11 Jahren.]

Hi David,
Thanks for explanation.

[David H Nebinger, geändert vor 11 Jahren.]

Yeah, didn't want to do this in your blog because a) I don't register for custom blogs like this, don't want to share my email address, etc., and b) having someone point out obvious flaws in a personal blog is, well, sometimes embarrassing, and I wouldn't want to do that...

Here things are (IMHO) a little more open for discussion re: what's the right way to do things, where folks who have some experience really should chime in...

Anyways, it was an interesting read. Maybe there is some valid use case out there that it might work for, and I just haven't stumbled upon it yet...

[David Ilechukwu, geändert vor 11 Jahren.]

Tanaji M. Londhe:

Hi David,
Thanks for explanation.

Tanaji -
I think the your scenario presents the exact fit for the Portlet IPC (Inter portlet communication) API - was included in Prtlet 2.0 API to solve problems like this.
Generally, you should stay away from changing portlet states from within another portlet (without the knowledge of the receiving portlet - Portlet B in your case). Like Nebinger advised - architectural best practices may not make this the best way to go. Such systems can quickly become a nightmare for maintenance too.

However, with IPC you can broadcast an event from a portlet - and have other portlets (who have registered to listen to such events) respond appropriately in their own portlet methods. That way - Portlet class B stays in command of the states of it's portlet pages.

Richard Sezov presents IPC in a very practical way in his book "Liferay in Action (and you can also download the sample). I think you should have a read.

A second word here: you could also achieve this using Liferay's Messaging Bus (which is a more robust API). It all depends on the time constraints of your project. I think IPC would be thequickest way for you to achieve this - without compromising software quality.

Hope this helps

Regards,
David

[David H Nebinger, geändert vor 11 Jahren.]

David Ilechukwu:

I think the your scenario presents the exact fit for the Portlet IPC (Inter portlet communication) API - was included in Prtlet 2.0 API to solve problems like this.

Well, not really. Portlet IPC is best in areas where the event sender does not know who will be listening (or how many). Tanaji's issue was dealing with sharing code, not really loosely coupled event handling.

A second word here: you could also achieve this using Liferay's Messaging Bus (which is a more robust API).

Messaging is more robust, but again it's targeting loosely coupled components, and not on sharing code... In both Portlet IPC and LMB, they are not really set up to handle a request/reply sort of scenario which makes using them as a foundation for shared code handling a challenging task...

So my suggestion to use SB was based off of Tanaji's desire to share code between multiple consumers. It's definitely a narrowly-scoped use case. As there are many ways to skin a cat, the SB solution was the best given the 'requirements'.

[David Ilechukwu, geändert vor 11 Jahren.]

Hi Tanaji, forgot to mention -
You could also refer the below thread to enable you get started quicker:
IPC Communication

[Tanaji M. Londhe, geändert vor 11 Jahren.]

Hi David,
Thanks for reply. Actually its like one portlet firing a event other portlet can listen.