Liferay upgrade issue: request attribute usage

[Aleksander Meterko，修改在9 年前。]

Hello.

We're developing portlet application using Liferay as a portal and Spring portlet framework. Till now we were developing our app on Liferay 6.1.2 CE, but lately decided to migrate to newest Liferay 6.2 CE GA2 and faced some issues, which could not handle by ourselves. I hope that LR community can point us in the right direction.

A little of background: for one of our mechanisms we needed to pass parameters from all portlets on current page to portal. One of examples here is that every portlet can declare inline javascript which should be invoked on it's rendering and for performance reasons these scripts should be placed at the bottom of the page (it allows to speed up page rendering by browser). Please note that this is just one of examples, other use same mechanisms for different purposes. Passing such values is performed by using request attribute and Liferay shared variable. So in our portlets we do:

Set<string> jsSet = request.getAttribute(LIFERAY_SHARED_inlineJS);
jsSet.add("<portletjs>");</portletjs></string>

To hook it up with the portal we've overridden Liferay's page bottom.jsp by placing:

request.getAttribute(LIFERAY_SHARED_inlineJS);

and printing all it's contents. It perfectly works in Liferay 6.1.2 CE, printing data from all portlets on current page, but fails on Liferay 6.2 CE GA2. To adapt this for new codebase these changes took place:
- bottom.jsp was modified according to it's new code in Liferay 6.2 CE GA2;
- made all portlets <ajaxable>false</ajaxable> to render synchronously with page;
- made all portlets <requires-namespaced-parameters>false</requires-namespaced-parameters> to be able to use same attribute from request;
- added to portal-ext.properties "request.shared.attributes=LIFERAY_SHARED_" as it seems required now.

After these changes I can see in debug mode that request attribute contains scripts from all portlets on the page, but on client-side first-win strategy takes place: on page rendering attribute contains scripts only for one portlet and this one portlet is changing on page refresh, which is typical for asynchronous race.

What should we fix or where should we continue our investigation? I hope you can help.

Regards, Aleksander.

[David H Nebinger，修改在9 年前。]

Aleksander Meterko:

What should we fix or where should we continue our investigation?

Sure, this one is easy.

Basically you should throw out all of this crap because it's not the right way to do it.

Each portlet has a liferay-portlet.xml file which defines for Liferay certain aspects for the portlets which go beyond the standard portlet.xml definition. The ones you're going to want to use here are the footer-portal-javascript and footer-portlet-javascript tags.

From the doco:

<!--
Set the path of JavaScript that will be referenced in the page's footer relative
to the portal's context path.
-->
<!ELEMENT footer-portal-javascript (#PCDATA)>

<!--
Set the path of JavaScript that will be referenced in the page's footer relative
to the portlet's context path.
-->
<!ELEMENT footer-portlet-javascript (#PCDATA)>

So you don't need to muck with the request attributes or anything, just define the JS to include either relative to the portal root or your portlet contexts and Liferay will include that javascript at the bottom of the page, just as your hack (excuse the term) does.

[Aleksander Meterko，修改在9 年前。]

Hello David.

Thanks for you answer, but unfortunately it's not an option for us. We intentionally did not use footer-portal-javascript / footer-portlet-javascript as needed javascripts are generated on the fly and there's no opportunity to hardcode this in xml file. Typical example: pass specific parameters from Spring portlet controllers to javascript model based on preferences values.