+1 for Birt to extras.
Most of the useful reports OOTB are currently fo.
+1 to JasperReports in extras. I'm happy to volunteer for that one.
Cheers,
Anne.
On 22 March 2012 04:59, Jacques Le Roux <jacques.le.r...@les7arts.com>wrote:
> From: "Olivier Heintz" <holivier.lis...@nereide.biz>
>
> Le 20/03/2012 15:31,
> adrian.crum@sandglass-**software.com<adrian.c...@sandglass-software.com>a
> écrit :
>>
>>> I like the idea of keeping reporting tools separate from OFBiz. In my
>>> experience, IT departments are already using a reporting tool for other
>>> applications and they would prefer to integrate that tool with OFBiz,
>>> instead of learning/using a new tool that comes bundled with it.
>>>
>> It will be nice if there is a default solution in OFBiz kernel to
>> maximize ready-to-use report and for small company which have not yet a
>> real reporting tool.
>>
>
> Then we have fo.ftl files and PDF rendering. Minimalistic but working.
>
> Jacques
>
>
>
>>> -Adrian
>>>
>>> Quoting Jacopo Cappellato
>>> <jacopo.cappellato@**hotwaxmedia.com<jacopo.cappell...@hotwaxmedia.com>
>>> >:
>>>
>>>
>>>>> 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
>>>>
>>>
>>>
>>>
>>>
>>>
>>
--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: (03) 9585 6788
Fax: (03) 9585 1086
Web: http://www.cohsoft.com.au/
Email: sa...@cohsoft.com.au
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
