Message Boards

Servlet for delivering portal header/footer

thumbnail
Gerhard Horatschek, modified 3 Years ago.

Servlet for delivering portal header/footer

Junior Member Posts: 86 Join Date: 3/20/09 Recent Posts
Hi all,
what is the best solution for delivering the header or footer of a liferay-portal via servlet  (friendlyURL/webservices ?) to make this available for other portals?
For example:  www.myportal.com/o/snippet/header delivers the header of the portal, which is called from www.anotherportal.com
We are using DXP 7.2.10 GA1
Thank you for help/information!
thumbnail
Olaf Kock, modified 3 Years ago.

RE: Servlet for delivering portal header/footer

Liferay Legend Posts: 6403 Join Date: 9/23/08 Recent Posts
Gerhard Horatschek:

Hi all,
what is the best solution for delivering the header or footer of a liferay-portal via servlet  (friendlyURL/webservices ?) to make this available for other portals?

There's no such thing as an isolated header or footer: It typically comes with some CSS and JS to make it appear in the positions where you want it, and with the colors, margins and fonts you like. Thus, only a portal page's header or footer doesn't exist in isolation and isn't served as such. It's always the full page, with certain parts embedded in it.
What's the underlying business problem that you're trying to solve?
thumbnail
Gerhard Horatschek, modified 3 Years ago.

RE: Servlet for delivering portal header/footer

Junior Member Posts: 86 Join Date: 3/20/09 Recent Posts
The business problem or the intention is, that the customer have a second portal (not Liferay), which should have the same header and footer as the Liferay portal. In this case our portal should act as a provider who deliver the header/footer.
I know that currently no such isolated function exists, and I know that there would be a lot of other obstacles - like CSS and JS (relative vs. absolute paths). But could there be any solution for this?
Currently we try to analyse this requirement and try to find out if there could be a solution, which is technical feasible.
If there is no possibility, we try to find out the complexity of the second portal functions and convince the customer to migrate this to our Liferay portal.
Thank you
thumbnail
Olaf Kock, modified 3 Years ago.

RE: Servlet for delivering portal header/footer

Liferay Legend Posts: 6403 Join Date: 9/23/08 Recent Posts
Gerhard Horatschek:

The business problem or the intention is, that the customer have a second portal (not Liferay), which should have the same header and footer as the Liferay portal. In this case our portal should act as a provider who deliver the header/footer.
I know that currently no such isolated function exists, and I know that there would be a lot of other obstacles - like CSS and JS (relative vs. absolute paths). But could there be any solution for this?
Currently we try to analyse this requirement and try to find out if there could be a solution, which is technical feasible.
If there is no possibility, we try to find out the complexity of the second portal functions and convince the customer to migrate this to our Liferay portal.
If it's only for the design part, it might be quicker to theme that other portal to look the same. This way you have full control with no dependency hell. Speaking of dependencies: it starts with bootstrap (are both systems on 100% identical versions? Does that other system use bootstrap at all?) but continuing with whatever else is included. If you need to include functionality in headers/footers: You can check the "share" option of Liferay's portlets, that enable you to share them on external systems. And if you frequently update header/footer content and want to do this in one place only, either such WebContent sharing might work, or accessing the content through the API.
As you ask this question on the Liferay forums, and suggest that a migration to Liferay is also an option: I'm biased, but that doesn't sound like a bad idea. Maintaining two systems that have huge overlaps in their purpose introduces quite a maintenance burden (with it: cost)
thumbnail
Gerhard Horatschek, modified 3 Years ago.

RE: Servlet for delivering portal header/footer

Junior Member Posts: 86 Join Date: 3/20/09 Recent Posts
It is unfortunately not only a design part, because the main navigation (of pages) is in the header and a navigation menu is in the footer, so it is not enough to use the share option of WebContent portlets or accessing the content via the API.
I agree, maintaining two systems means a lot of effort and costs. And that's why the customer want to analyse this scenario.
A last technical question regarding this (ignoring all the dependency issues for now): can it be an approach to make a servlet and get the (rendered?) content of the portal_normal.ftl via ThemeUtil.include like in the class RenderFragmentEntryStrutsAction:
            Document document = Jsoup.parse(
                ThemeUtil.include(
                    httpServletRequest.getServletContext(), httpServletRequest,
                    httpServletResponse, "portal_normal.jsp", layoutSet.getTheme(),
                    false));
thumbnail
Olaf Kock, modified 3 Years ago.

RE: Servlet for delivering portal header/footer

Liferay Legend Posts: 6403 Join Date: 9/23/08 Recent Posts
The rendered content for portal_normal.jsp contains everything from <html>, </head>, <body> etc., including the references to Liferay's theme, CSS, JS libraries included and so on. I'd consider it a nightmare to just use this to construct anything else than an extremely simple static page. You state that you'll use this for another portal, implying that it in turn will have its own JS, CSS to include with unknown conflicts. You'll get much more than just the HTML markup.

I'd rather recommend to retrieve the navigation.
A simple way: Even the navigation menu in the header of Liferay's classic theme can be shared (Configuration / Share)
Or you can enumerate the pages through the API (probably you want to cache the result) and use the result to rebuild the navigation on the external portal.

Or just use the time you'd use to simulate a Liferay navigation on that other system to move everything over to Liferay (you judge what is more effort - short term and long term)