An overview of a few enhancements to reporting for 3.4. See the respective pacman issue for details.

There's been some interesting debate on RIA's in the past few days. I've been mulling over the points raised, and trying to figure out if I grasp the whole situation as well as I thought. Ted Leung spurred the discussion with this post:

There's a good read over at Artima discussing RIA's that ties in a little bit with what I talked about in my previous post. I tend to agree with the author about Flash/Flex. But I still have a problem with its proprietary nature. And even though its free at the lowest level, I just can't commit to a platform I may have to pay for when I try to do anything complicated. As much as I want to like Flex, I still favor what I am seeing from the WPF/E guys. WPF/E still suffers the from the installation problem since it will take years to enjoy the same penetration as Flash (if it ever does). And the toolkit needs to mature to some parity with what Flex offers to be a serious contender for a RIA platform.

Its taken me a long time to wrap my head around this concept of semantic HTML and using CSS to avoid presentational markup. I see the benefit, but I have enough experience to know its just not always possible in the real world. Particularly in web apps, for which HTML wasn't designed to address. So I've tried to embrace it to as much as possible and thought I had done a reasonably good job, using valid XHTML markup and valid CSS for styling. But after reading two books, I realized I could go a lot further.

I've been searching for a better web interface for at least 3 years. Probably longer. The core problem lies in HTML. Being designed as a semantic markup language, its just not capable, or designed to be used for laying out user interfaces. People have gone to considerable lengths to hide that fact by wiring up all sorts of JavaScript and CSS. But sooner or later (usually sooner) you're going to hit a wall and realize, "Oh yeah, this just wasn't designed for what I want to do".

Today I checked in the core pieces for my "PointTable" solution. Its actually called a BGrid and its going to come out of the box with four pieces: BComponentGrid, BGridTable, BGridLabelPane, and BGridEditor. (I know the naming sort of stinks - you got any suggestions?)

Today I checked in the inaugural version of the new ReportService for 3.2. Its a baby step, but I expect this to become the hub for a set of powerful analysis tools in Niagara AX.

The last time I talked about this topic, the focus was on how to ease the process of creating table-like visualizations of station data in a px page. Ends up, that was a very narrowly defined take on a much more general problem.

Update (26 Jun 07) None of this work really made it into 3.2 because of scheduling and other priorities. Unfortunately, its not slated for 3.3 either. But I still want to keep this list around so we have these requests captured should we commit to them in a future release. So if you have a feature request, please add it in the comments! - AndyF

In almost every station I have seen, I always see at least one "table" of points that was created by hand using a grid of BoundLabels. Creating these suck. And if its so common, then why isn't there a better way?