3

I am currently trying to add basic JSF (2.0) support to Backbase Portal 5.2.1.2 to use in my custom widgets.

It seems to be working when I access my widget in a static way (e.g. ".../portal/static/portal_name/widgets/widget_name/index.xhtml"), but when I view my widget in the context of a portal (.../portal/portals/portal_name/pages/index) my JSF tags are shown in the HTML source as instead of the parsed output. The same happens to EL variables like #{msg.title}.

If I use the same JSF setup in a 'normal' webapp project, it works just fine as well, so in my eyes, there must be something Backbase specific that is causing this issue.

I would like to know what is causing this to happen, if it could be solved or circumvented or if anyone has successfully managed to implement JSF in this specific version of Backbase. I know implementing JSF worked in Backbase 5.1, but for me it's not an option to revert to that version.

Edit - Added the widget's index.xhtml by request (My actual index.xhtml is slightly bigger, but this fails as well):

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core" xml:lang="en">
<h:head>
    <meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />
    <title>Help ribbon widget</title>
    <link rel="stylesheet" type="text/css" href="css/style.css" />
</h:head>
<h:body>
    <span class="left title">#{msg.help_title}</span>
    <h:outputText value="TEST"/>
</h:body>
</html>

Additionally I am using a Border_Layout for my container template if that is of any help.

When I go to Google Chrome inspector's network tab, and look at the request for the widget's index.xhtml file, I can see the correct output, but for some reason this is not the same as what is shown in the combined html.

Charles
  • 50,943
  • 13
  • 104
  • 142
tmetten
  • 132
  • 1
  • 8

1 Answers1

4

The problem with this approach is that widget definitions are not currently expected to contain dynamic content.

I'd guess that in your scenario, the *Border_Layout* container is server sider rendering (SSR) the widget. When this happens, if your widget's src URL is relative, the portal will simply read the file from disk and the faces servlet will never be invoked. This is normal, the definition is expected to be static. But there are two immediate solutions:

Firstly, you can switch to client side rendering (CSR). This will result in the client making a http request for the widget definition and it being accessed via the faces servlet. Easiest way to achieve this is to use a custom page template which does not contain a <b:include> tag. This solution does mean it will not work with JS disabled though.

If, however, you wish to keep using SSR, you can use an absolute url for your widget's src property. This means the server needs to make an http request for the widget, thus running it through the faces servlet. There is one more problem here; As the Portal Server expects widget definitions to be static, it will aggessivley cache it, so you'll need to switch off widget caching.

I wouldn't really recommend both of these solutions though in the longer term. I'd recommend you run your JSF app independently in a separate context and then find a way to include it in a widget. You could try to setup something with Backbase Mashup Services, but I'd recommened a simple iframe approach. If you require, I can provide you with a more advanced iframe Backbase widget for creating seamless iframes (no scrollbars etc).

If you need any more support, I'd encourage you to sign up at https://my.backbase.com. Backbase's new support site where you should receive more dedicated help, docs and code samples.

Phil Mander
  • 1,819
  • 15
  • 20
  • I mean "not contain dynamic content, other than the Backbase specific widget/gadget tag library" – Phil Mander Sep 20 '12 at 10:55
  • I tried this today, and a custom CSR page template indeed did the trick and was the easiest solution. I then tried to make only the portlet CSR instead, but to no avail. For now, I'll be sticking with this initial solution. Also, I already have a My Backbase account and I was planning on posting this question on there as well, but then your answer popped up. :) Thank you Backbase! – tmetten Sep 24 '12 at 06:58