Tag: widgets

Missing passthru_nonProxyHosts for IBM Connections widget proxy

When writing widgets for IBM Connections (version 1, 2, 3 and 4) and you have an iWidget (judgement still out on the OpenSocial gadget support) that needs to talk to other network resources than the IBM Connections server you need to change the proxy-config.tpl to work around the same origin policy restrictions imposed on JavaScript running in a browser. The change is easy enough and well documented but what do you do if you need to use a HTTP proxy for requests leaving your network? Well you use the passthrough proxy setting for the proxy (see ) to make sure that traffic passes through your HTTP proxy. The problem however is if you need to use a HTTP proxy to access resources external to your network but not to access internal resources since the setting is global and applies to all rules. So be warned and plan your network accordingly.

For the record there is a setting in Mashup Center to work around this (passthru_nonProxyHosts) but that setting hasn’t been implemented for IBM Connections unfortunately.

Reusing IBM Connections Atom date formatting for custom widgets


In a recent IBM Connections project I needed to display dates in the same as IBM Connections does it that is full dates sometimes but also using “yesterday”, “today” etc. Plus it needed to cater for the fact that the customer might at some future point in time allow the user to change the UI language. Coding this is tedious and would take quite some time so I wanted to figure out if IBM Connections had some libraries that could help me.

And it did.

By messing around in Firebug I found out that the way IBM Connections does it is by using a nifty JavaScript object called lconn.core.DateUtil.AtomDateToString. This object is actually a helper object that does two things – first it is able to convert an Atom date/time string (such as 2012-08-01T12:44:42.713Z) into a JavaScript Date object and then format it according to i18n settings and the language set in the UI.

Once I knew what to look for in the IBM Connections code it was simple enough. They do it by adding a hidden span-tag (CSS class “lotusHidden”) with a special tagging CSS class called “formatDate” as shown below.

<span class="formatDate lotusHidden">
  2012-08-01T12:44:42.713Z
</span>

Then using dojo.query they locate the nodes with the formatDate CSS class, use the utility class to convert the Atom date string and then remove the “lotusHidden” CSS class to make it visible.

// expand dates
if (lconn && lconn.core && lconn.core.DateUtil &&
lconn.core.DateUtil.AtomDateToString) {
   dojo.query(".formatDate", root).forEach(function(item){
      item.innerHTML=lconn.core.
         DateUtil.AtomDateToString(item.innerHTML);
      dojo.removeClass(item,"lotusHidden");
   });
}

Fixing a wierd widget installation issue (Content is not allowed in prolog)

For our OnTime Group Calendar 2011 Notes user interface which is Java plugin based we have seen some strange problem reports with customers reporting that the widget installs but after installation an error message is displayed on screen (“The widgets below had issues during the installation. See the log for more details.”). The wierd thing about the reports were that the customers reported that the widget (and hence the plugins) actually installed just fine and worked after a client restart. What’s even funnier is that the same plugins installed without error if the customer used HTTP and not NRPC for their update site access protocol. In the log (Help/Support/View Trace) the below error messages was shown (my highlighting):

Could not access digest on the site: no protocol:
   0/8E4DFE3996CBDD94C1257A33003CE3A9/$file/digest.zip
[Fatal Error] :1:1: Content is not allowed in prolog.
org.eclipse.ui.WorkbenchException: Content is not allowed in prolog.
	at org.eclipse.ui.XMLMemento.createReadRoot(Unknown Source)
	at org.eclipse.ui.XMLMemento.createReadRoot(Unknown Source)
	at com.ibm.rcp.dynamic.extensions...
	at com.ibm.rcp.dynamic.extensions...
	at com.ibm.rcp.dynamic.extensions...
	at com.ibm.rcp.toolbox.internal.management...
	at com.ibm.rcp.toolbox.internal.management...
	at com.ibm.rcp.toolbox.internal.management...
	at com.ibm.rcp.toolbox.internal.management...
	at com.ibm.rcp.toolbox.internal.management...
	at org.eclipse.core.internal.jobs...
Caused by:
org.xml.sax.SAXParseException: Content is not allowed in prolog.
	at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
	at org.apache.xerces.jaxp.DocumentBuilderImpl...
	... 11 more

This really had me scratching my head.

After reseaching and Googling I found a post called “Java: “Content is not allowed in prolog” – causes of this XML processing error” which led me in right direction.

When I opened the widget XML file in an editor and switched to HEX mode I saw this:



3 invisible bytes were inserted at the start of the file. I copy/pasted the XML into a new file which solved the issues. The 3 bytes actually turn out to be what’s called a Byte order mark or BOM for short. From the wikipedia article I found out that the BOM for a UTF-8 file is those exact bytes and I did save the file as UTF-8 in my editor.

The UTF-8 representation of the BOM is the byte sequence 0xEF,0xBB,0xBF. A text editor or web browser interpreting the text as ISO-8859-1 or CP1252 will display the characters  for this.

But the bytes were not there in my editor but only in the file that I received from a customer. So how did the bytes get there?!

So after more research and playing around I found out that the BOM is added by Notepad on Windows. But of course!! A lot of customers receive the XML file and change the update site URL to point to their own servers and if they use Notepad for this the BOM is added (see “The Notepad file encoding problem, redux” for more details).

But how to fix it? Telling customers not to use Notepad to edit the XML file would be a no-go as many probably no not use another editor. And even if they did the problem would probably still arise in some situations and we would spend time diagnosing it. The solution I’ve opted for is to change the encoding of the file to ASCII and change the encoding declation in the XML file to ASCII as well. The content of the XML file is unchanged and now customers can change it using Notepad without issues.

Diagnosing wierd widget installation issue

I had a customer report a widget (plugin) installation issue to me. They had clients being unable to install a widget (and hence a plugin) from an update site on our servers (external to their network). The error was reported as below:

Unable to access "http://<host>/site.xml".
Contains: Error parsing site stream. [White spaces are
   required between publicId and systemId.]

The issue turned out to be caused by a firewall issue and hence wrongly reported in the log. The issue was solved by relocating the update site to the customers network.

Enough with all the widget specifications already!!

After what feels like a cascade of widget specifications (iWidget, Google Gadget, Wookie) the World Wide Web Consortium (W3C) is working on a widget specification to unite them all. If you’re interested in stuff like this I recommend this developerWorks article (W3C widget configuration and packaging (Learn about the candidate specification for W3C widgets)).

Good thing is that we’re still talking JavaScript, CSS and HTML so existing widgets should be pretty easy to port if need be.