IBM Connect is a great opportunity to meet new people, as are any user groups (quick shameless plug for Engage next month). It’s also a great opportunity to return envigorated and engaged. We’ve seen a new release of the Extension Library during Connect as well as the announcement of the XPages Knowledge Base thanks to some hard work by John Jardin over the Christmas period. Hopefully the coming months will see some interesting announcements from OpenNTF as well, if my enthusiasm on that doesn’t get redirected, and I intend to get stuck into Darwino too.

But it’s also great to see new community members stepping outside their comfort zones and starting blogging. I’m always happy to help promote blogs, because I’m very mindful of being awestruck by comments from the likes of Tim Tripcony and Nathan T Freeman on my own blog when I started off. I’m also mindful of that terrifying thought “what on earth could I possibly contribute?”. But XPages is such a broad area that there is a wealth of potential and, at the very worst, what you contribute is easy indexing for answers to your questions. Often you blog about something someone else struggled with but was too afraid to blog about or ask about on StackOverflow. Even if you blog about a problem, if you’ve spent some time doing a bit of investigation, your post might get read by someone who has a vested interest in finding a solution or knows something that can help. This point is important – if you’re putting some effort in, trying to be positive in your delivery and trying to help others yourself, others will be more inclined to help you. The other good thing about our community is it is a lot more good-natured than some: rarely, if ever, will you get shot down in flames because our community is generally inclined to be positive.

So when CaySal Lackey, who I met at IBM Connect, pointed me in the direction of her blog and I saw a blog post about a problem she was having with the Data View, the stack trace covered and background that it had been fine in previous versions both gave plenty of information to do some simple digging. Because the Extension Library is open source, available on GitHub and therefore has an auditable history, it only took a few minutes to see what lines were changed when. The workaround offered on the blog thanks to taking the time to investigate the problem – adding a Summary Column – also seemed a strange resolution. After a very short email exchange, it was apparent CaySal was using a Summary Facet and gave me steps to reproduce the scenario. From what I had seen of the source code, it seemed a plausible probability that the writeDataColumn method would not abort immediately (because there was a summary area), but would fail on viewDef.summaryColumn.getTitle() because there was no Summary Column, just a Summary Facet. That hypothesis would also explain why adding a blank Summary Column was a workaround.

It took me a while to get back to testing my hypothesis, but as I suspected I had an application in production with a Summary Facet and no Summary Column. So the blog post, the investigation, the workaround, the source code, my production application all meant I had a vested interest in confirming the hypothesis. When I upgraded to the latest Extension Library and tested it, it confirmed the hypothesis. As expected, when I wrapped the relevant lines that tried to get properties from the Summary Column in checks for whether viewDef.summaryColumn was null, the view worked as previously. And I had clear steps to reproduce and a definite vested interest in submitting the fix. A bit more investigation also confirmed it’s only a problem for the Bootstrap Data View renderer, not the OneUI version. (Ironically, I had problems building the Extension Library and my Eclipse settings reformatted all the lines, so testing it and trying to amend Eclipse settings to get the lines back to their original formatting took longer than coding the fix, creating the issue on GitHub and submitting the pull request!)

With great synchronicity, this tweet appeared in my timeline this afternoon:

That seems very fitting, and why blogging + reproduceable scenario + community + open source enables a fix. (And if anyone urgently needs that fix, I should be able to package it up.) In my opinion, it also highlights the benefit of using open source code rather than the risks: bugs can exist in any release, whether it’s open source or officially supported code; but open source releases like Extension Library make it easier to confirm the cause for an issue, give a wider support base for suggesting a resolution, often enable quicker turnaround (official or unofficial) and hopefully make it easier for fixes (or enhancements) to be included in the core. I look forward to more of the XPages components also being open sourced.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top