L) framework/birt (and related dependencies/reports spread around): move to
"Extras"
M) framework/bi (and related dependencies - ecas/business rules and data - spread
around): move to "Extras"
This is an area where Hans and I are in disagreement and we didn't get much
feedback from others.
So I would like to explain here why I think we should move the Birt component
and the Birt reports out of the framework and
consider them as optional tools.
There are currently 18 reports in the applications implemented with Birt; but
they really seem experiments rather than something
really usable; to give you some examples:
* in most of them there is this code like this:
userLogin = null;
try {
userLogin =
delegator.findByPrimaryKey("UserLogin",UtilMisc.toMap("userLoginId","admin"));
} catch(e) {
Debug.logError(e,"");
}
* all the retrieval logic (scripts) is inlined with layout definition and this
is something we try to avoid in all the existing
screens
* entity list iterators are not properly closed
* some of the widget based financial reports have been converted to Birt: their
layout is still very simple and comparable to
the widget based versions available before Birt; so the conversion to Birt
added a dependencies on this component without adding
real value (the rptdesign files mix together data preparation scripts and ui
definitions and in order to maintain them you have
to use the Birt designer); also some of them are now broken: Income Stetements,
Balance Sheet etc... This is probably caused by
the recent refactoring of JSR-223 but the original widget based PDF are still there and are working fine...
* building a report with this Birt integration still requires a lot of development work (similar to the one required to create a
screen); but then the code in the rptdesign is very difficult to maintain without the editor
My questions are:
* do you really think that this way of integrating rptdesign reports is the
answer to fill the gap of a good reporting tool in
OFBiz? Are you actually using this integration for your reports?
* do we all agree to make this Birt integration the best practice mechanism for all OFBiz reports?
* do you really think that we should replace all the existing widget generated
reports and FOP reports with rptdesign reports
built using the existing Birt integration under the framework?
If any of your answers will be "no" then in my opinion it would be much better
to:
1) make Birt integration an optional component, downloaded separately
2) move the existing rptdesign reports out of the applications and keep them in
the external Birt component
3) at this point users will have the option to use the Birt component or not,
but the ootb code will be clean and without
dependencies on it; most of all, we will not deliver reports that looks similar
(ugly) but they are implemented randomly with
Birt or Widgets 4) start evaluating, as a community, what should be the best
practices for ootb reports: what is the tool we
want, what are the minimal requirements etc... and then work together to get it
in place and then migrate all existing reports
to it in order to have a consistent system; if the community will not be able
to reach a consensus on this, then we should leave
the decision about the reporting tool to use to the end user
I think that the Birt integration is a nice optional component, and I see that
there may be interested parties, but in its
current status it is not something ready for becoming the primary reporting tool for the ootb applications.
Jacopo
