MicroStrategy Web SDK - WTFs

MicroStrategy's Web SDK did something I totally didn't expect: calling WebReportInstance.getPrompts() actually runs the report if the report has no prompts. WTF??

This is a big deal if the report takes a long time to run.  I would expect a method called getPrompts to, you know, get the list of prompts.

After a few rounds with support, I got the answer:

reportSource.setExecutionFlags(EnumDSSXMLExecutionFlags.DssXmlExecutionResolve);

Note that call is on the ReportSource before getting the ReportInstance.

Same goes for Documents.

Speaking of WTF's with MicroStrategy's Web SDK - even though all subclasses of WebResultSetInstance (documents and reports) implement a getMessage() method that returns a subclass of WebMessage, the method is implemented only on the individual subclasses.

In other words, instead of this:

class WebResultSetInstance { public WebMessage getMessage() }

you get this

class WebDocumentInstance { public WebDocumentMessage getMessage() }
class WebReportInstance { public WebReportMessage getMessage() }

This is annoying, because it prevents you from doing something like this

resultSetInstance.getMessage().removeFromInbox()

interchangeably with a report or document.  You need to treat both report and document cases separately.

KnockoutJS is great, not so sure about PagerJS

I've been using KnockoutJS for a while and I like it.  Knockout solves a clear need for me, in that without it or something similar, I'd have a mess of jQuery event handlers that breaks every time my HTML markup changes.  And because Knockout only solves for data binding, it is simple and easy to learn. It was easy to learn after using JSF on the server, with a similar two-way binding model.  I imagine .NET developers would have a similar transition from XAML, WPF, etc.

The one thing I am not as happy with was extending Knockout with PagerJS for client-side routing.  Although it's easy to get started with Pager, it doesn't seem to work well with the use case where only one page is active at a time and each page has its own isolated view model.  Pager does have mechanisms to lazy fetch templates and bind view models when a page becomes active, but the DOM and the view model don't go away when you move to another page.

This might be ok for some use cases like master/detail, or tabbed navigation on a single page.  But it seems like the growing memory footprint will cause problems when the DOM and view models for multiple independent pages are all in scope when they don't need to be.

Ideally there would be some way to dispose view models and DOM whenever we leave one page for another.