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.

Web stacks that support change - but what kind?

I've recently made a transition from using dependency-injection heavy Java frameworks (Spring, Java EE) to full-stack dynamic language frameworks like Grails, Django, Ruby on Rails etc.

With these full-stack frameworks, you need much less code to get something done, between the magic of dynamic languages, and the elimination of dependency injection .  As a result it's easier to iterate rapidly as business requirements change, because there's fewer places to touch and fewer layers of indirection to sort through.

It made me wonder whether dependency injection in Spring and Java EE was intended to address a different kind of flexibility - flexibility to change out pieces of the tech stack.  I feel like this kind of flexibility is still a hangover from EJB 2.x.  The legacy use case was something like this: maybe EJB won't always suck so you put your business logic in a service that gets injected, and you could replace your POJO implementation with an EJB without changing the dependencies.

I feel like the flexibility from dependency injection was overrated - think about how often during the typical lifecycle you make a significant tech stack change, and think about how much time you spend wading through all those extra layers of indirection and configuration to make a functional change.  Also, these days with the proliferation of viable technologies, you are almost as likely to try something totally different (node.js, perhaps?) than to change out your ORM in isolation.

Yes, things are better today with annotations and better dynamic bytecode generation (e.g., no gratuitous interface with single implementation).  Still it feels like dynamic proxies are a clumsy mechanism for providing services like transactions, when compared with frameworks that provide these capabilities through dynamic language features or closures.  Given the choice, I think I'd rather go with a tech stack that makes it simpler and more efficient to address business requirement changes, even if it makes it harder to switch between EclipseLink and Hibernate.