Liferay and Bigpipe. possible ?

[Victor Doss, geändert vor 12 Jahren.]

I am trying to see if it is possible to make liferay send response in facebook "big pipe" like chunks so it will start to render right away. There are two parts to it.

1) Wrapping page layout and portlet markup inside script tags.
2) Flushing after every segment is ready.

Turned out the first part is easy. RuntimePortletUtil.java already has a clean separation page template and portlet markups. So wrapping with a <script> tag and assembling on the client was easy. Also striped the portal_normal.vm to minimal (just $content_include). We got that working.

But the flushing was the hard part. Initially when I saw the response object in RuntimePortletUtil, I was excited and just called flush(). Nope! nothing happened. It can't be that simple. After looking at LayoutAction.java I realized the whole output from RuntimePortletUtil.java is received as a string and set in WebKey.LAYOUT_CONTENT, which is then used in portal/layout.jsp by the tiles layer. The portal_normal.vm route is triggered from /common/themes/portal.jsp which get the LAYOUT_CONTENT as $content_markup ?

So now I am in the unfamiliar territory of struts and tiles. Even though I got my output to look exactly as big pipe output, its still not "chunked" . Whatz the point ? Throwing this out there for experts to chime in if it is even possible ?

Adding my notes below. Do let me know if I got something wrong.
------------------------------------------------------------------------------------

struts-config.xml: /c/portal/layout mapped to LayoutAction.
  --> LayoutAction.includeLayoutContent: [code][code][code]

RequestDispatch to portlet.jsp. Sets the output to WebKeys.LAYOUT_CONTENT
--> /portal/layout/view/portlet.jsp: Gets content of /layouttpl/*/*.tpl
--> RuntimePortletUtil.processTemplate(): Calls mergeTemplate() on page layout *.tpl files.
--> RuntimePortletUtil.processPortlet(): For each portlet on page.
--> PortalUtil.renderPortlet(): returns portlet markup for each portlet.
--> PortalImpl.renderPortlet(): RequestDispatch to render_portlet.jsp
--> /portal/render_portlet.jsp: initialize lot of portlet specific stuff.
--> InvokerPortletImpl.render()
-->LayoutAction.java: findForward('portal.layout)
--> WEB-INF/tiles-def.xml ( 'portal.layout' maps to /portal/layout.jsp )
--> /portal/layout.jsp: Gets the WebKeys.LAYOUT_CONTENT


tiles-def.xml ( /common/themes/portal.jsp )
--> /common/themes/portal.jsp: has tag <liferay-theme:include page="portal_normal.jsp">
--> taglib.util.ThemeUtil.include(): includeVM() replaces portal_normal.jsp to portal_normal.vm
---> ThemeUtil.java: mergeTemplate: "portal_normal.vm"
---> /themes/(classic)/template/portal_normal.vm - $content_include = "content" from tiles portal.layout, set in VelocityVariables.java - look for tilesContent

[Victor Doss, geändert vor 12 Jahren.]

Getting the actual response instead of the wrapped response in RuntimePortletUtil did the trick. Something like..

PrintWriter out = ((HttpServletResponseWrapper)response).getResponse().getWriter();

..and calling flush() after every portlet output. Have to comment out bunch of filters as well (GZip, strip etc). The response has "Transfer-Enoding" chunked on the client side.
Now the content of portal_normal.vm are not showing up. Need to digg more...

[Victor Doss, geändert vor 12 Jahren.]

ok. Turned out that was just some unrelated changes I made in VelocityVariable that was messing up. So, to answer my own question. Yes - its possible to create bigpiple like output with liferay. But then anything is possible in software world. I will post a blog soon with details if anyone is interested.