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
