Portlet to Portlet submit v. IPC

[Debopam Mitra, modifié il y a 9 années.]

I was thinking what would be the best choice, for sending a data from one portlet to another portlet.

All I want to do is to take a input from one portlet and send it to the action phase of another portlet.

I know to achieve a flow where a form in one portlet directly submits to the process action of another flow is through the following:

<%@ taglib uri="http://java.sun.com/portlet_2_0" prefix="portlet"%>
<%@ taglib prefix="aui" uri="http://alloy.liferay.com/tld/aui"%>
<%@ taglib uri="http://liferay.com/tld/portlet" prefix="liferay-portlet" %>
<portlet:defineobjects />


<liferay-portlet:actionurl var="actionURL" portletName="portlet_2_WAR_InterportletPostportlet" windowState="maximized" />
<aui:form action="<%=actionURL%>" method="post">
	<aui:input name="message" label="Enter Your Message" />
	<aui:button type="submit" value="Submit" />
</aui:form>

In this scenario my portlet_1 & portlet_2 are in the same page. Although the data has been received in the processAction of portlet_2, a problem surfaces. The problem is the portlet_1 that is in the same page is gone.

Q 1. Is the redirection that is happening removing the portet_1?
Q 2. How can I solve this?

Even if I solve this, my main question for this thread:

Is this the right process methodology to send the data? Or I need to implementing server side eventing?

[Debopam Mitra, modifié il y a 9 années.]

Answers to Q1 & Q2. I have set the windowState to maximized and looking for the other portlet to show up. Not possible. So I change windowState="maximized" to windowState = "normal".


Any way the main question still remains, in these scenario should I have used IPC or Portlet to Portlet submit is good to go?

[Olaf Kock, modifié il y a 9 années.]

Q2: You can solve this by describing the problem that you want to solve with this. This will make it possible to propose an alternative solution that doesn't mean posting from one portlet to the other through the action phase.

Think of portlets as distinct architectural boundaries. There's nothing to ensure that both portlets will be on the same page, and they're completely separated from each other by design. If you want them to interact, you'd have to break down this border knowingly. Whoever is maintaining your portlets in the future might not expect such behaviour and will most likely be somewhat puzzled by the behaviour you implement.

Rather than "crossposting" to each other's action handler, I'd suggest to 1) have a common business layer, where both portlets share their state, so that changes made in one portlet have an effect on the other. Or 2) use Inter-Portlet-Communication (e.g. Events or Public Render Parameters) to distribute changed state between the two.

I don't like most alternatives of DOM manipulations within "the other portlet's part of the DOM". This typically creates hard-to-maintain systems. You might need some client-side portlet interaction if you have an Ajax-heavy solution that doesn't involve a complete roundtrip to the server. But even in this case I wouldn't recommend to manipulate the DOM, rather introduce a client side event-notification system. Not understood? Well, I consider this a heavy solution anyways, and would recommend it only in a few select cases. Stick with the first suggestions

[Debopam Mitra, modifié il y a 9 années.]

Thanks, for this clear concept.

But again a question arises,

by

have a common business layer, where both portlets share their state, so that changes made in one portlet have an effect on the other.

,

you mean what ?

[Olaf Kock, modifié il y a 9 années.]

Portlets are a UI concept - you'll hopefully have a business layer that the portlets provide the UI for, and it's easy to have multiple portlets access the same business logic. Just share some of your state (e.g. the current customerId) so that multiple portlets can show multiple aspects of a customer. If one portlet changes data, the others can show this updated data.