RE: [JIRA?]RE: Custom Layout - Adding portlet dynamically

[Gonçalo Dinis, geändert vor 11 Jahren.]

Hello,

Liferay version: 6.1.1

I'm following Liferay SDK tutorials and everything seems perfect. First the Portlet tutorial, then Themes and now the Layout. The "default" website that is bundled with the SDK is also impressive as it does everything I'm looking for when searching for a Portal product.

Now I've stumbled in something I wasn't expecting any difficulties to implement. The following page http://www.liferay.com/documentation/liferay-portal/6.1/development/-/ai/lp-6-1-dgen05-embedding-portlets-in-a-layout-template-0 demonstrates how to add a portlet to a custom Layout.

I tried to add a custom portlet:

$processor.processPortlet("TestLifeRay_WAR_TestLifeRayportlet")

Where the ID was obtained following the intructions on the tutorial mentioned above. Doing this I got a NullPointerException at

com.liferay.portal.model.PortletConstants.getRootPortletId

Then I proceeded with trying the same thing but now using stock portlets (the Search portlet):

[code]$processor.processPortlet("3")

Resulting in the same exception.

Then I added the Search portlet manually into an existing page of the demo portal and inspected the ID using Look & Feel -> Advanced Styling. The ID was

portlet_3

.

Also tried

portlet_3

and got NullPointerException. Then I added the same Search portlet to another page and noticed that the Search portlet Id was

p_p_id_3_

.

This inconsistency made me very apreensive on this subject. Maybe it's just the presentation of the ID, or the ID in the context of this current page.

Going back to the main subject, can anyone help me with this one? I'm not able to get the portlets loaded into the page. I get null pointers with both custom and core portlets. The exception is thrown and

$processor.processPortlet("3")

is presented instead on the page.

Thank you,
GD

[Gonçalo Dinis, geändert vor 11 Jahren.]

Other info that might be useful:

The portlet looks correctly configured since I can add it to an existing page by using the "Add" functionality directly from the management tools in a random live page. But when I add it to a Layout using the the technique in the previous post, it fails with NullPointerException.

Thanks
GD

[Gonçalo Dinis, geändert vor 11 Jahren.]

Hello again,

I managed to get the portlet to at least show up in the layout using:
$theme.runtime("TestLifeRay_WAR_TestLifeRayportlet", "", $velocityPortletPreferences.toString())

I followed some examples here on the forum so I came up with $theme.runtime. The problem now is that when I interact with the portlet it's state is not saved. The portlet is just the one used in the tutorial where we have a text field that is changed while on edit mode.

I'm using an action to acomplish this feature. When I add the portlet manually everything works flawlessly. If I add the portlet to the layout directly in the template, the portlet show up but the changed inserted in edit mode are nor persisted.

When info is not persisted the following is logged:
Reject processAction for http://localhost:8080/web/guest/eee/-/my-greeting/edit on TestLifeRay_WAR_TestLifeRayportlet

Checking in debug I confirm that the action is not being called.

I tried to compare the form action URL both in the manually added portlet and the one added in the Layout and it looks the same:
http://localhost:8080/web/guest/eee/-/my-greeting/edit?p_auth=7ehFoUGn&p_p_lifecycle=1&_TestLifeRay_WAR_TestLifeRayportlet_javax.portlet.action=setGreeting

What could be possibily wrong?

Thanks again
GD

[Satheesh Ravi, geändert vor 11 Jahren.]

Make the portlet non-instanceable. It means make it <instanceable>false</instanceable> . To make the action call you need to use actionURL and override processAction method of GenericPortlet or MVCPortlet in your portlet class. I'm not sure where you are going wrong. Need some specific info.

[Gonçalo Dinis, geändert vor 11 Jahren.]

Hello,

Back again to this issue.

The portlet is already non-instanceable.

The method processAction is already overriden (note: in this phase I'm already using actionURL with a specific method other than processAction as you can see in the URL written to the stdout Reject processAction). Anyway I reverted this and I'm using the default processAction again and I confirm that the error message is still written to the stdout and the action is never executed.

I'm adding the portlet to the Layout using:
$theme.runtime("TestLifeRay_WAR_TestLifeRayportlet", "", $velocityPortletPreferences.toString())

Remember that when we add the portlet to a page using the admin control panel everything works ok. This is only happening when we add the portlet in the Layout template.

We will now proceed to inspect the differences between the POST request when the portlet is added manually and when the protlet is added in the template.

We need help from Liferay experts to solve this blocking this issue.

Thanks
GD

[Gonçalo Dinis, geändert vor 11 Jahren.]

POST is exactly the same. The only thing that changes is the request URL as we are in different pages.

We already tried to add the portlet into Layout project dependencies in liferay-plugin-package.properties Layout file and got the same results.

When we submit in edit mode, the Reject processAction message is shown in the output, the action is not hit and the interface remains in edit mode, with the previous data it had before posting changes...

[Gonçalo Dinis, geändert vor 11 Jahren.]

We are attaching this simple test case in hope that someone can help us.

The attachment contains a very simple layout and a very simple portlet (very similar to the tutorials on Liferay website). The portlet is added to the layout in the velocity template.

Thanks for any help
GD

[Gonçalo Dinis, geändert vor 11 Jahren.]

Hello,

We reproduced the same example in Liferay 6.0 using the sample that is attached to our previous post and everything worked OK.

Should we open a JIRA issue on this subject?

Note: When deploying in 6.0 we used 6.0 semantics in our sample JSP's (ie. replacing <portlet:param name="mvcPath"... by <portlet:param name="jspPage" )

Thanks
GD

[Tejas Kanani, geändert vor 11 Jahren.]

Hi Gonçalo,

Yes. It's a issue with Liferay 6.1.1. I've also tried to add portlet inside layout and it didn't work for me as well. Even I've also tried to add Liferay OOTB portlet(Search) but same result with printed out the entire line. After some investigation finally found the issue with Liferay Code.
When you are actually using $processor, It's just an object of com.liferay.portlet.layoutconfiguration.util.velocity.TemplateProcessor.java. And issue is in that class only. If you check processPortlet method which is expecting portletId string param(where our portletId is being passed).

public String processPortlet(String portletId) throws Exception {
	try {
		_request.setAttribute(
			WebKeys.RENDER_PORTLET_RESOURCE, Boolean.TRUE);

		return RuntimePortletUtil.processPortlet(
			_servletContext, _request, _response, null, null, [b]_portletId[/b],
			null, false);
	}
	finally {
		_request.removeAttribute(WebKeys.RENDER_PORTLET_RESOURCE);
	}
}

But if you check inside that method its never being used. And instead global _portletId is used. So here is the issue. It should be portletId(which we are passing) instead of _portlet(global variable).
So it should be

return RuntimePortletUtil.processPortlet(
			_servletContext, _request, _response, null, null, [b][i]portletId[/i][/b],
			null, false);

I've also tried with modifying portal-impl.jar with modified class file and its working fine for me.
I am not sure if anyone has created jira issue for the same. I've not found any. So you can create one.

Regards,
Tejas

[Tejas Kanani, geändert vor 11 Jahren.]

Found JIRA issue for the same. So its already created.
http://issues.liferay.com/browse/LPS-29278

[Gonçalo Dinis, geändert vor 11 Jahren.]

Tejas,

Thank you for the response.

We stopped using $processor about a couple days ago and tried to use instead $theme.runtime and even this way we are getting incorrect behavior, as detailed in our last couple of posts.

We can see in that JIRA issue you linked that this work around might produce a different behavior: "Theme templates can use $theme.runtime(), but calling it in layout templates does not produce desired effect". Even that way, the work around fails completely in our case and gives "Reject processAction".

We only have one option from now that is to get Liferay 6.1.1 GA source code, change it and compile ourselves. The other option is to move to another Portal product, but I'm struggling not to do it. I really liked Liferay MVC approach and flexibility (we will use only custom portlets, custom layouts, custom themes, etc. No out-of-the box components). We will see if it's worth the effort of building from source, or in another words if the build process is configured to be a simple ant "build all" similar task.

Finally I would also like to manifest my opinion on this issue. I think it's quite strange that this one got through a GA release. We are for sure not the only ones who use custom layouts with custom portlets. It seems something trivial that any Portal that leverages the complexity to a minimum must use.

Thanks for the assistance!

GD

[Gonçalo Dinis, geändert vor 11 Jahren.]

Back to this issue again.

The "Reject processAction" is happening because the _typeSettingsProperties member of class com.liferay.portal.model.impl.LayoutImpl is missing the property that maps columns to portlets in that column.

Example from the sample we atached:
column-1=TestLifeRay_WAR_TestLifeRayportlet

This property has not been set so going back a little bit in the nested calls, the following "if" will evaluate to false, which in turn is causing the problem:

com.liferay.portal.util.PortalImpl
.
.
if (layoutTypePortlet.hasPortletId(checkPortletId)) {
   return true;
}

The _typeSettingsProperties member of class com.liferay.portal.model.impl.LayoutImpl is a bit hard to keep track where it is set, because is setted with the value of typeSettings of com.liferay.portal.model.impl.LayoutCacheModel, which in turn is a public members so it's no easy to track.

I will not spend any time tracking the origin of these typeSettingsProperties. We will just set a list containing the names of our custom portlets and make it accessible in public boolean isAllowAddPortletDefaultResource(HttpServletRequest request, Portlet portlet). If the portlet being evaluated is in that list this method will return true and the Rejected processAction will not be a problem.

I know that this is a very bad approach, and may cause severe impacts on other functionalities related to our custom portlets or the Portal itself, but it will be like this until a fix is available. If we find this to have short term severe impacts that affect the Portal functionality, like permissions on portlets or other stuff, we will stop doing it and look for other alternatives.

Thank you all who may provide any help on this.
GD

[Paras Jain, geändert vor 11 Jahren.]

Thanks Tejas,

That patch is doing the trick for me

[Vishal Panchal, geändert vor 11 Jahren.]

Hi Tejas,

Thank you for the post.


Regards,
Vishal R. Panchal