On Mar 22, 2012, at 12:43 PM, Erwan de FERRIERES wrote:

> Le 22/03/2012 02:38, Hans Bakker a écrit :
>> Jacopo,
>> 
>> you are making here a very negative review of the Birt integration....as
>> any component sure there is room for improvement however....
>> 
>> Some positives you did not even notice?
>> 
>> 1. can use minilanguage for the retrieval
>> 2. can use ofbiz fieldnames and entity names. (not databasenames)
>> 3. can use OFBiz views.....
>> 4. can fully integrate in the ERP application.
>> 5. has many inbuilt output formats.
>> 6. Incorporates the warehouse entities.

Please note that all the above points are covered also by screens/FOP; and the 
code in screens/FOP is cleaner and implements the MVC pattern as all the other 
screens.
You didn't mention the only one reason that really makes meaningful to consider 
this Birt integration: after you have manually implemented (in the traditional 
way) controller entries, screens to run the reports and the data preparation 
code (that needs to be inlined in the Birt report definition) you can use the 
Birt designer to implement the ui.
This is in my opinion a nice to have for an optional component but not enough 
to make it the default reporting engine for OFBiz.

>> 
>> Created/extended the datawarehouse which is essential for ordereporting.
>> We have very big customers where using order reports directly on the
>> OFBiz database was not possible.
>> 
>> This warehouse function is essential for large customers

These ones are not part of the Birt integration but are instead part of the BI 
framework that I originally designed (and you have expanded): in fact I still 
see a big potential for this tool, that it is for its nature optional and 
external to OFBiz (ideally it should run in a separate db) and I really hope to 
see it more exposed tomore contributors in the future if delivered as an 
optional application.

>> 
>> I very strongly think about keeping this in the framework.
>> 
>> BI component I agree, can go....
>> 
>> Regards,
>> Hans
>> 
>> 
> 
> I'm in two minds about BIRT. It's a fine tool to make reports, but underused 
> in OFBiz.
> If the concerns Jacopo has about it were resolved, will it be kept in 
> framework ?

In its current status I don't see how this could happen; it was not a good move 
that some of the ootb reports have been converted to Birt because now we have 
another technology for reporting that it is not enough to become the primary 
tool; the reports generated using this tool in its current form are simply not 
good enough to stay; if we will ever want to deliver with the framework an 
official tool for reporting then its requirements/features should be carefully 
evaluated before taking a decision

> Also, creating more of those reports (with not available features in FOP), 
> will this go in the right way to keep it there ?

I don't think that adding more Birt reports to OFBiz to make the OFBiz 
applications more dependent on this imperfect Birt integration would be the 
right way to go. Instead we should rather gather all the requirements, 
design/select the proper tool (Birt of what else) and then integrate it 
properly and finally convert all the application reports to it. But even if we 
will reach that point I would see some potential to treat it as an 
optional/separated tool (but this can be discussed).
In summary my opinion is: for now *this* Birt integration should go to Extras 
and improved there; interested users will get it from there (together with the 
reports); if the community thinks we should have a default reporting tool 
packaged in OFBiz then we will start the architectural/requirement design phase 
(at that point we could even bring back again some of the existing Birt code, 
if we think it is the right way to go).

Jacopo

> 
> 
> -- 
> Erwan de FERRIERES
> www.nereide.biz

Reply via email to