nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Alfresco integration in Liferay

jhoueix

Hello everybody!

I have the following problem:

I have installed the liferay portal on a server, and I want to integrate Alfresco functionnalities as a portlet in this portal. The problem is that Alfresco is running on a remote server.

So I can't use Alfresco portlets as shown in the following article:
http://wiki.alfresco.com/wiki/Deploying Ã¢â‚¬Â¦ Liferay4.3

I have tried to integrate existing webscript portlets (for example MyWebSpaces): I made a portlet which call the URL of the webscript, and then juste display the content of the response. But the problem is that the content of the response (which is finally the content of my portlet) make calls in a local way (ex: call to javascript scripts, css files, etc.). It can't works in my situation because my Alfresco is running on a remote server.

I'm a little worried. Does anybody have a solution to integrate Alfresco in a portal in any way? :?

Thank you for you responses and sorry for my english (I'm french…)

Find more posts tagged with

Comments

mikeh

Hi

I think the guys on the Liferay forums might be in a better position to help you, as I think this is probably more a Liferay configuration question than an Alfresco one.

e.g. http://www.liferay.com/web/guest/community/forums/message_boards/message/279380?_19_threadView=flat

Thanks,
Mike

jhoueix

In the webscript, the variable ${url.context} is called to locate the CSS and javascript files. The problem is that ${url.context} = "/alfresco", which is a relative URL and so the files are searched in the local server and not the remote server where is installed Alfresco. Is there a way to change this variable so that ${url.context} = the complete URL to Alfresco (for example, ${url.context} = http://122.10.10.10/alfresco")?

Thank you for your responses.

mikeh

Hi

No, not unless you patch the URLModel in source code or edit the web scripts by hand.

However, I would question exactly how you're going about this. Presumably you've created an HTTP Client, which downloads the portlet HTML and presents it in Liferay. Effectively you're acting like a proxy server, therefore it's the responsibility of that HTTP Client code to parse all the URLs present in the HTML before presenting it to the browser.

The hole you'll dig for yourself is that (a) it's not a trivial process to parse URLs in an HTML document (unless in a browser DOM) and (b) you'll also have to parse Javascript and CSS files, which may also contain URLs.

I would suggest there are two ways forward:
1 - See how other people are doing this already with Liferay
2 - Use an IFRAME for the portlet

Thanks,
Mike

dgenard

Hi,
we have the same issue when integrating Alfresco web scripts in a J2EE application.
We don't use a portal, but our J2EE application acts as a proxy in a similar way. All requests go through a front servlet which manages security, online payments, … The servlet then calls the alfresco webscript, but cannot deliver the result without rewriting the URLs. As you said, this is a tedious task.
- Modifying templates is no good option, as we would like to use standard Alfresco webscripts such myspace,…
- Using an IFRAME is also not a good option, because following requests would bypass our front servlet.

So, if we could in some way control the value of ${url.context}, this would greatly simplify the use of webscripts in such context. In example, an additional url param might be used to set the value of ${url.context}.

We may modify the URLModel class to implement such a logic, but we think other Alfresco developers might have similar needs.

Regards, Denis

ugocei

I find it hard to reconcile MikeH's answer with Alfresco's trumpeting of WebScripts and HTTP APIs as the new, cool way to develop applications. If we have the problem of rewriting all URLs whenever we need to present a script's output in a portal, what are HTTP APIs that return HTML good for?

mikeh

I find it hard to reconcile MikeH's answer with Alfresco's trumpeting of WebScripts and HTTP APIs as the new, cool way to develop applications. If we have the problem of rewriting all URLs whenever we need to present a script's output in a portal, what are HTTP APIs that return HTML good for?

I don't know whether you've misunderstood the problem this topic was addressing, or web scripts as a whole, but I'm going to assume the former…

The portlets we included with Alfresco "out of the box" were designed to be used either within the Alfresco web client itself, in a portal webapp running on the same Tomcat instance (e.g. Liferay), or within an iframe (e.g. a Netvibes.com style site). We didn't expect people to use them in a proxied client environment, hence the problems reported with the relative URLs. It would be a trivial process to override the portlet scripts, either on the classpath or within the repo, and update them to make all URLs absolute rather than relative. It's somewhat more complicated to parse the output and rewrite them - but that's what proxy servers must do. The failing of just parsing the HTML and not the Javascript and CSS files (and subsequent AJAX calls, etc.) is that relative URLs will remain "broken".

The suggestions I posted have nothing to do with the viability of Alfresco web scripts as a technology for developing applications - whether the scripts be for rendering portlets, ajax snippets, HTML includes, whole pages, XML, ATOM… or whatever - but of the shortcoming of the relatively simple demo portlets we developed in-house.

Mike

ugocei

Mike, I see your point. However, I would expect Alfresco to provide more Web Scripts out of the box.

I am pushing the Web Scripts solution to a long string of customers, but right now I am having difficulties because the existing (2.1) scripts are few and poorly documented. For example, I cannot even find a simple script to display a document's metadata.

I hope this is a temporary situation, and that we will see many more and more useful scripts in the next releases.