Part 1 was about API’s and SPI’s, part 2 about Mobile, part 3 about security and “coherent-ness”. This part will be about apps/extensions this time moving to on-premises.
For on-premises the extension model for IBM Connections is iWidgets and OpenSocial gadgets. You can extend Profiles, Communities and Homepage. OpenSocial is only supported in Homepage. IMO the former two (Profiles and Communities) are probably the ones mostly extended using widgets. Unfortunately these also use the oldest extension mechanism but also the most capable one. I have presented numerous times on iWidgets (e.g. see Easy as Pie – Creating Widgets for IBM Connections).
In essence an iWidget consists of:
- A widget descriptor – an XML document describing the widget and which is pointed to in the IBM Connections on-prem setup (widgets-config.xml). The widget descriptor may also contain static HTML for the widget e.g. a “Loading…” text.
- A JavaScript “class” having methods for various parts of the widget lifecycle such as onLoad, onView, onEdit etc.
- Zero or more resources loaded by the widget descriptor before control is passed to the JavaScript. This can be JavaScript files, CSS files etc.
Besides being the worstly formatted document I’ve even seen the iWidget specification is pretty easy to follow. The specification allows for pretty powerful extensions to IBM Connections but has major drawbacks the worst being:
- Creating a simple dynamic widget is pretty involved failing the “fast HelloWorld test”. Also something simple as setting a nice widget title takes i18n files and editing LotusConnections-config.xml as well.
- IBM proprietary – at some point IBM Mashup Server used iWidgets as well but I think the product has been discontinued with IBM Connections being the only container using iWidgets now
- No development environment available. Only way to develop is to either use a full IBM Connections instance with the caching-hell that ensues or write an iWidget wrapper/emulator. I prefer the latter and it’s not hard but really shouldn’t be necessary.
- The widgets all run as part of the page so there is no containment from a CSS perspective (a “rouge” CSS class will mess up the entire page), from a JavaScript perspective (a “rouge” piece of JavaScript both stop the entire page from loading and/or read data from the entire page).
These are pretty bad but as a developer you can learn to live with them and work around them. The worst is the last item where a failing widget makes the entire page fail to load something that seems to even affect the IBM supplied widgets.
This being said you can develop almost anything using iWidgets. You may talk to any HTTP based API using XHR whether the same source as where the widget code was loaded from or not. Worst case is that you use the built-in AJAX proxy to tunnel requests that work to work around same-origin-policy issues or if the API supports CORS you can go nuts and load data to your heart’s content. The only real issue is that to convey user identity from the IBM Connections WebSphere Application Server (WAS) to a proprietary – or non IBM server (without support for LtpaToken cookies) – is tricky. Developing a simply app deployed on WAS or Domino to created an encrypted assertion of the user identity is not hard but could – and should – be part of the platform and not something I as a developer should have to worry about. It’s a situation that is pretty easy to imagine would happen and IBM should have addressed it.
All things considered the iWidgets approach is proven works for most ISV/product situations or customer engagements I’ve been involved in. I’m just happy we and/or no customer has asked us to extend areas other than Profiles and Communities yet…
lekkimworld.com 