Confusion through documentation

In working with the CEWolf (which I believe stands for: Chart Enabling... um, Wolf) I came across a pretty fundamental question: how do you let the framework know when a chart can be reused vs. when it should be rebuilt?

Conveniently, there is a method that does just that and is located in an extremely logical (and convenient) spot. Now to figure out how to use it... here's the classes javadoc.

1. The method is called "hasExpired" and returns a boolean, which indicates to me that if I return "true": the data "has expired". So, if I want to regenerate I should return true.

2. The javadoc states: "If the data which had already been used for chart rendering is still valid this method should return true". Ok... so, I guess if I want to regenerate I should return false.

3. The javadoc goes on to say: "...there is no guarantee that the dataset production is always avoided if this method returns true". This seems to go along with #2 again: while returning true doesn't guarantee anything, it does mean we'll at least attempt to avoid reproduction: so, if I want to regenerate I should return false.

4. And finally, the javadoc wraps up with: "Returns: true if the data which had been produced with the passed in parameters has expired since its creation, false otherwise". Which seems to basically restate what I was thinking in #1. So, (in my thinking) if I want to regenerate I should return true.

Well, I guess that since #1 and #4 are based on my interpretations while #2 and #3 are blatently telling me that my interpretation is wrong, I am going to start with returning false when I want to regenerate... but I don't like it. and even if return false does regenerate: I'm going to have to test to make sure that's right. Kinda stinks.

The IT gravy train must be derailed

"The IT gravy train must be derailed", Robert Cowles (WI State Senator). An article on WTN (Monday) reports on several state senators calling for an audit of state-government IT spending.

Overall I agree with the theme presented in a couple press releases from last Friday: an audit seems like a very healthy thing to do.

Projects run over budget: it happens. Projects run way over budget: sometimes you can't avoid that either. When it's happening consistently though, it's time to take a step back to identify and address what's going wrong.

My only disagreements with the releases are on fairly subtle and somewhat minor points:

• The fact that a someone is "high paid" (or that something has a high price tag) doesn't mean that they're overpriced and/or not worth it... Doesn't mean they are worth it either, but you need to take a closer look to make that call.


• Having to spend $1.5 million in the middle of a $47 million project just to make sure you're moving in the right direction is unfortunate. but in all likelihood, if the key players think that it's worthwhile: it's going to save you money in the end.

Paging with displaytag

While upgrading a few things (struts, cewolf, etc) on an application we did last year I came across something odd in the implementation of displaytag. We had a custom "paging" solution implemented.

It's not a huge deal but I figured I could stand to be a little more familiar with displaytag anyway so I went ahead and made the changes to rely on more displaytag functionality.

The only thing that I'm really missing is a "display all" function. This I had to kind of hack in - of course, it's easy to "display all": just don't use paging. What I'm missing though is the ability to use paging, but also provide a link to disable/re-enable it. I ended up putting in a bit of a hack solution that I'm not unhappy with... but I'd certainly like to get rid of. Seems like there must be something like this built in that I'm missing?

The joys of changing requirements

A good "Overheard" yesterday.

Sadly, requests like this are not at all infrequent. but while this is certainly a funny post... working with the users instead of just for the users, on their requirements, could probably have avoided the whole dilemna.