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
