This project has moved and is read-only. For the latest updates, please go here.


This Page should explain a bit more about the concept and vision of this project and the outcome.


During my works I've seen many reporting technologies. Crystal Reports, Telerik Reporting, List & Labels, Microsoft Reporting Services (and LocalMod of it) and MS Access (no comment).

All of them have one in common: They tightly coupled with a project or solution.

Some would argue and explain that this is good and anything else would be ridiculous.. In my opinion I would disagree. Sometimes it would be great to be more flexible with deployment and add new reports. Sometimes it's important to fix a mistake and not compile a whole project/solution.

The same goes with dynamical reports. People like to "play around" with Filter Settings and watch if the result is what they expected. So what now? Create a application based on business logic and group all reports of the same style and create a static filter?

Break the Chains

So this where cRumble steps in. The concept behind this solution is the uncoupled approach of each reporting related topic.

Not a replacement, an extension

cRumble will not replace any Reporting Technology. It will just offer a kind of wrapper for give more freedom and flexibility to your preferred Reporting Technology.

Blueprints and Requirements

One small but essential difference in cRumble is the usage of reporting technology. All Reports act as Blueprint, not as finished reports as usually it would.
  • The report defines the data (Select Statement, CSV Structure, etc) but not necessary the source (Database, Filename, etc).
  • The Report contain the Report Layout (based on used Technology),
  • The Report contain the parameters (linked with Filter or Dynamically) and link them to logic (where to use them)
  • The Report contain a list of necessary Filter-Views (for the parameters)

So even though the report itself contain many information for rendering, it cannot run without the controller. The same goes for all the information. There uncoupled with all pro (flexibility) and cons (possible exception by use of non existing filter, etc).

One for all

Filter are essential and the worst case would be a filter for each report and ignore any redundancy.

cRumble make it possible to use a Filter as Plugin. So it's possible to define a Filter for many reports.

With an override logic within the Report, its possible to transform any Filter Output to match the usage within report. So it doesn't matter if the Filter returns a DateTime and you need only Date or Time.

The Filter doesn't care who need him. It only cares about the restriction it receive.
For example you can create a Filter for Location and the Report can ask for this Filter, but also define a restriction that it only need the zip-code/city and anything else can be hidden.

The Filter does not need the same data source as the report (it's just the flexibility, I know in most scenarios it wouldn't make any sense).

The "Big Brother"

The Controller is "The Big Brother" of cRumble.
It checks for Filter and Report, which implement the Interface.

As soon you call a valid report, the controller will collect all Blueprint Data of the Report. It will make the link to the filter and create a View with Filter and Report. It will watch for Filter Calls and pass them to the report. The Report itself will transform them and send the new Data-Command which will be processed by the controller.


As you may now have a clue.. cRumble tries to uncouple filter, data, layout and rendering in small pieces and link them on runtime.

This give the possibility to add fast a new report or fix/extend a filter without huge impact. It would also make (later) possible to mix technologies and data sources up to an insane level..

But I'm honest and say: It's a long way to a first release of cRumble (at least alone)

Last edited Sep 12, 2013 at 2:00 PM by Telaran, version 1