You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ja...@hotwaxmedia.com> on 2012/03/20 12:47:02 UTC
Lose Weight Program for OFBiz - Birt and BI
>
> 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
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Scott Gray <sc...@hotwaxmedia.com>.
I think BIRT should be moved to Extras. The main reasons being:
- we're still not (IMO) giving enough power to the users themselves to create reports
- not every company wants to use BIRT and nor should they have to
- the engine is large, the integration is lightweight and last time I looked the API was pretty poorly documented
IMO the best thing we could do for reporting in OFBiz is to provide some type of HTTP based data provider interface. Virtually every reporting tool can consume CSV or XML formatted data from web resources and it would allow user's to cut up the data any way they liked via their reporting tool of choice (even something like Excel could be used). We could consider creating some new entities and a UI for controlling what data can be published and to who, possibly even creating a UI that allows dynamic view entities to be constructed and published.
Even this idea is possible to deploy as a hot-deploy component so doesn't necessarily need to exist in the framework but it's certainly a much more generic and accessible approach than what we have with BIRT (which it should be noted wasn't chosen for it's features but rather because it was the only one with a permissive license for inclusion).
Regards
Scott
On 26/03/2012, at 8:25 PM, Jacques Le Roux wrote:
> Which is one of reasons to have mostly unused things (not only BIRT) out of OFBiz.
> BTW from this POV the POS is not a problem, since it's not a webapp, it runs only at demand...
>
> Jacques
>
> Anne wrote:
>> Just for the record, we disable the birt container. I don't like loading
>> things I know aren't being used.
>>
>> Cheers,
>> Anne.
>>
>> On 23 March 2012 22:33, Mansour Al Akeel <ma...@gmail.com> wrote:
>>
>>> in the config for base:
>>>
>>> base/config/ofbiz-containers.xml: <!-- load the BIRT container -->
>>> base/config/ofbiz-containers.xml: <container name="birt-container"
>>> class="org.ofbiz.birt.container.BirtContainer"/>
>>>
>>>
>>> This is what loads Birt. Not sure if there's something else needed to load
>>> it.
>>> Can this be temporary used until OSGI is introduced. OSGI makes it
>>> easy to load and unload any component. So (if done properly), no
>>> integration in the framework should be done. In this case Birt
>>> component should contain the logic to load its self when deployed into
>>> OSGI container. So those who needs it can just install it with one
>>> command.
>>>
>>> In the mean while, cleaning the code base will make it easier to look
>>> into the messy code in framework, and remove what is not needed. Which
>>> will help bringing new things like OSGI to the table.
>>>
>>>
>>> On Thu, Mar 22, 2012 at 7:58 PM, Anne <an...@cohsoft.com.au> wrote:
>>>> +1 to Mansour's comments.
>>>>
>>>> I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and
>>>> Groovy I currently
>>>>
>>>>>> 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.
>>>>
>>>> (points are from Hans earlier email, though maybe my idea of "fully
>>>> integrate" isn't the same as Hans). I presume I can also incorporate the
>>>> warehouse entities, and use minilang (Hans' other two points), though I
>>>> haven't yet tried either. Maybe it is easier to do these things with Birt,
>>>> but I don't have any difficulty with JasperReports.
>>>>
>>>> More importantly to me, if I decide to drop JasperReports and move to
>>>> something else later, it won't be very difficult.
>>>>
>>>> I am sure Hans integration of Birt would be very useful for those who use
>>>> Birt, and I expect they appreciate his effort. If Birt was in Extras,
>>>> perhaps some of those people would be more likely to contribute to its
>>>> maintenance.
>>>>
>>>> Cheers,
>>>> Anne.
>>>>
>>>> On 23 March 2012 01:37, Mansour Al Akeel <ma...@gmail.com> wrote:
>>>>
>>>>> I don't know why birt is integrated with Ofbiz. A reporting tools, is
>>>>> an add-on to any database driven system, and not essential for the
>>>>> over all functionality. Yes all of us need reports, and most of the
>>>>> time we use a reporting engine, but why can't it be separated from the
>>>>> code base, and used as a separate application ?
>>>>>
>>>>> From my perspective, the core should contain only components needed to
>>>>> bring it up to a functional state. Entity Engine, Service Engine, fall
>>>>> under this category. Some may argue that UI should be considered as
>>>>> well, and this is valid argument. But when it comes to reporting
>>>>> engine, I don't think so.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES
>>>>> <er...@nereide.fr> 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.
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>> 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 ?
>>>>>> Also, creating more of those reports (with not available features in FOP),
>>>>>> will this go in the right way to keep it there ?
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Erwan de FERRIERES
>>>>>> www.nereide.biz
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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: sales@cohsoft.com.au
>>>>
>>>> Bonsai ERP, the all-inclusive ERP system
>>>> http://www.bonsaierp.com.au/
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Jacques Le Roux <ja...@les7arts.com>.
Which is one of reasons to have mostly unused things (not only BIRT) out of OFBiz.
BTW from this POV the POS is not a problem, since it's not a webapp, it runs only at demand...
Jacques
Anne wrote:
> Just for the record, we disable the birt container. I don't like loading
> things I know aren't being used.
>
> Cheers,
> Anne.
>
> On 23 March 2012 22:33, Mansour Al Akeel <ma...@gmail.com> wrote:
>
>> in the config for base:
>>
>> base/config/ofbiz-containers.xml: <!-- load the BIRT container -->
>> base/config/ofbiz-containers.xml: <container name="birt-container"
>> class="org.ofbiz.birt.container.BirtContainer"/>
>>
>>
>> This is what loads Birt. Not sure if there's something else needed to load
>> it.
>> Can this be temporary used until OSGI is introduced. OSGI makes it
>> easy to load and unload any component. So (if done properly), no
>> integration in the framework should be done. In this case Birt
>> component should contain the logic to load its self when deployed into
>> OSGI container. So those who needs it can just install it with one
>> command.
>>
>> In the mean while, cleaning the code base will make it easier to look
>> into the messy code in framework, and remove what is not needed. Which
>> will help bringing new things like OSGI to the table.
>>
>>
>> On Thu, Mar 22, 2012 at 7:58 PM, Anne <an...@cohsoft.com.au> wrote:
>>> +1 to Mansour's comments.
>>>
>>> I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and
>>> Groovy I currently
>>>
>>>>> 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.
>>>
>>> (points are from Hans earlier email, though maybe my idea of "fully
>>> integrate" isn't the same as Hans). I presume I can also incorporate the
>>> warehouse entities, and use minilang (Hans' other two points), though I
>>> haven't yet tried either. Maybe it is easier to do these things with Birt,
>>> but I don't have any difficulty with JasperReports.
>>>
>>> More importantly to me, if I decide to drop JasperReports and move to
>>> something else later, it won't be very difficult.
>>>
>>> I am sure Hans integration of Birt would be very useful for those who use
>>> Birt, and I expect they appreciate his effort. If Birt was in Extras,
>>> perhaps some of those people would be more likely to contribute to its
>>> maintenance.
>>>
>>> Cheers,
>>> Anne.
>>>
>>> On 23 March 2012 01:37, Mansour Al Akeel <ma...@gmail.com> wrote:
>>>
>>>> I don't know why birt is integrated with Ofbiz. A reporting tools, is
>>>> an add-on to any database driven system, and not essential for the
>>>> over all functionality. Yes all of us need reports, and most of the
>>>> time we use a reporting engine, but why can't it be separated from the
>>>> code base, and used as a separate application ?
>>>>
>>>> From my perspective, the core should contain only components needed to
>>>> bring it up to a functional state. Entity Engine, Service Engine, fall
>>>> under this category. Some may argue that UI should be considered as
>>>> well, and this is valid argument. But when it comes to reporting
>>>> engine, I don't think so.
>>>>
>>>>
>>>>
>>>> On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES
>>>> <er...@nereide.fr> 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.
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> 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 ?
>>>>> Also, creating more of those reports (with not available features in FOP),
>>>>> will this go in the right way to keep it there ?
>>>>>
>>>>>
>>>>> --
>>>>> Erwan de FERRIERES
>>>>> www.nereide.biz
>>>>
>>>
>>>
>>>
>>> --
>>> 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: sales@cohsoft.com.au
>>>
>>> Bonsai ERP, the all-inclusive ERP system
>>> http://www.bonsaierp.com.au/
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Mansour Al Akeel <ma...@gmail.com>.
Thank you Anne.
Perfect.
I think options like this can be made visible through some documentation.
At least inside the code through comments.
I know it's there for BIRT.
On Sun, Mar 25, 2012 at 8:09 PM, Anne <an...@cohsoft.com.au> wrote:
> Just for the record, we disable the birt container. I don't like loading
> things I know aren't being used.
>
> Cheers,
> Anne.
>
> On 23 March 2012 22:33, Mansour Al Akeel <ma...@gmail.com> wrote:
>
>> in the config for base:
>>
>> base/config/ofbiz-containers.xml: <!-- load the BIRT container -->
>> base/config/ofbiz-containers.xml: <container name="birt-container"
>> class="org.ofbiz.birt.container.BirtContainer"/>
>>
>>
>> This is what loads Birt. Not sure if there's something else needed to load
>> it.
>> Can this be temporary used until OSGI is introduced. OSGI makes it
>> easy to load and unload any component. So (if done properly), no
>> integration in the framework should be done. In this case Birt
>> component should contain the logic to load its self when deployed into
>> OSGI container. So those who needs it can just install it with one
>> command.
>>
>> In the mean while, cleaning the code base will make it easier to look
>> into the messy code in framework, and remove what is not needed. Which
>> will help bringing new things like OSGI to the table.
>>
>>
>> On Thu, Mar 22, 2012 at 7:58 PM, Anne <an...@cohsoft.com.au> wrote:
>> > +1 to Mansour's comments.
>> >
>> > I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and
>> > Groovy I currently
>> >
>> >>> 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.
>> >
>> > (points are from Hans earlier email, though maybe my idea of "fully
>> > integrate" isn't the same as Hans). I presume I can also incorporate the
>> > warehouse entities, and use minilang (Hans' other two points), though I
>> > haven't yet tried either. Maybe it is easier to do these things with
>> Birt,
>> > but I don't have any difficulty with JasperReports.
>> >
>> > More importantly to me, if I decide to drop JasperReports and move to
>> > something else later, it won't be very difficult.
>> >
>> > I am sure Hans integration of Birt would be very useful for those who use
>> > Birt, and I expect they appreciate his effort. If Birt was in Extras,
>> > perhaps some of those people would be more likely to contribute to its
>> > maintenance.
>> >
>> > Cheers,
>> > Anne.
>> >
>> > On 23 March 2012 01:37, Mansour Al Akeel <ma...@gmail.com>
>> wrote:
>> >
>> >> I don't know why birt is integrated with Ofbiz. A reporting tools, is
>> >> an add-on to any database driven system, and not essential for the
>> >> over all functionality. Yes all of us need reports, and most of the
>> >> time we use a reporting engine, but why can't it be separated from the
>> >> code base, and used as a separate application ?
>> >>
>> >> From my perspective, the core should contain only components needed to
>> >> bring it up to a functional state. Entity Engine, Service Engine, fall
>> >> under this category. Some may argue that UI should be considered as
>> >> well, and this is valid argument. But when it comes to reporting
>> >> engine, I don't think so.
>> >>
>> >>
>> >>
>> >> On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES
>> >> <er...@nereide.fr> 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.
>> >> >>
>> >> >> 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
>> >> >>
>> >> >> 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 ?
>> >> > Also, creating more of those reports (with not available features in
>> >> FOP),
>> >> > will this go in the right way to keep it there ?
>> >> >
>> >> >
>> >> > --
>> >> > Erwan de FERRIERES
>> >> > www.nereide.biz
>> >>
>> >
>> >
>> >
>> > --
>> > 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: sales@cohsoft.com.au
>> >
>> > Bonsai ERP, the all-inclusive ERP system
>> > http://www.bonsaierp.com.au/
>>
>
>
>
> --
> 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: sales@cohsoft.com.au
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Anne <an...@cohsoft.com.au>.
Just for the record, we disable the birt container. I don't like loading
things I know aren't being used.
Cheers,
Anne.
On 23 March 2012 22:33, Mansour Al Akeel <ma...@gmail.com> wrote:
> in the config for base:
>
> base/config/ofbiz-containers.xml: <!-- load the BIRT container -->
> base/config/ofbiz-containers.xml: <container name="birt-container"
> class="org.ofbiz.birt.container.BirtContainer"/>
>
>
> This is what loads Birt. Not sure if there's something else needed to load
> it.
> Can this be temporary used until OSGI is introduced. OSGI makes it
> easy to load and unload any component. So (if done properly), no
> integration in the framework should be done. In this case Birt
> component should contain the logic to load its self when deployed into
> OSGI container. So those who needs it can just install it with one
> command.
>
> In the mean while, cleaning the code base will make it easier to look
> into the messy code in framework, and remove what is not needed. Which
> will help bringing new things like OSGI to the table.
>
>
> On Thu, Mar 22, 2012 at 7:58 PM, Anne <an...@cohsoft.com.au> wrote:
> > +1 to Mansour's comments.
> >
> > I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and
> > Groovy I currently
> >
> >>> 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.
> >
> > (points are from Hans earlier email, though maybe my idea of "fully
> > integrate" isn't the same as Hans). I presume I can also incorporate the
> > warehouse entities, and use minilang (Hans' other two points), though I
> > haven't yet tried either. Maybe it is easier to do these things with
> Birt,
> > but I don't have any difficulty with JasperReports.
> >
> > More importantly to me, if I decide to drop JasperReports and move to
> > something else later, it won't be very difficult.
> >
> > I am sure Hans integration of Birt would be very useful for those who use
> > Birt, and I expect they appreciate his effort. If Birt was in Extras,
> > perhaps some of those people would be more likely to contribute to its
> > maintenance.
> >
> > Cheers,
> > Anne.
> >
> > On 23 March 2012 01:37, Mansour Al Akeel <ma...@gmail.com>
> wrote:
> >
> >> I don't know why birt is integrated with Ofbiz. A reporting tools, is
> >> an add-on to any database driven system, and not essential for the
> >> over all functionality. Yes all of us need reports, and most of the
> >> time we use a reporting engine, but why can't it be separated from the
> >> code base, and used as a separate application ?
> >>
> >> From my perspective, the core should contain only components needed to
> >> bring it up to a functional state. Entity Engine, Service Engine, fall
> >> under this category. Some may argue that UI should be considered as
> >> well, and this is valid argument. But when it comes to reporting
> >> engine, I don't think so.
> >>
> >>
> >>
> >> On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES
> >> <er...@nereide.fr> 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.
> >> >>
> >> >> 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
> >> >>
> >> >> 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 ?
> >> > Also, creating more of those reports (with not available features in
> >> FOP),
> >> > will this go in the right way to keep it there ?
> >> >
> >> >
> >> > --
> >> > Erwan de FERRIERES
> >> > www.nereide.biz
> >>
> >
> >
> >
> > --
> > 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: sales@cohsoft.com.au
> >
> > Bonsai ERP, the all-inclusive ERP system
> > http://www.bonsaierp.com.au/
>
--
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: sales@cohsoft.com.au
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Mansour Al Akeel <ma...@gmail.com>.
in the config for base:
base/config/ofbiz-containers.xml: <!-- load the BIRT container -->
base/config/ofbiz-containers.xml: <container name="birt-container"
class="org.ofbiz.birt.container.BirtContainer"/>
This is what loads Birt. Not sure if there's something else needed to load it.
Can this be temporary used until OSGI is introduced. OSGI makes it
easy to load and unload any component. So (if done properly), no
integration in the framework should be done. In this case Birt
component should contain the logic to load its self when deployed into
OSGI container. So those who needs it can just install it with one
command.
In the mean while, cleaning the code base will make it easier to look
into the messy code in framework, and remove what is not needed. Which
will help bringing new things like OSGI to the table.
On Thu, Mar 22, 2012 at 7:58 PM, Anne <an...@cohsoft.com.au> wrote:
> +1 to Mansour's comments.
>
> I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and
> Groovy I currently
>
>>> 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.
>
> (points are from Hans earlier email, though maybe my idea of "fully
> integrate" isn't the same as Hans). I presume I can also incorporate the
> warehouse entities, and use minilang (Hans' other two points), though I
> haven't yet tried either. Maybe it is easier to do these things with Birt,
> but I don't have any difficulty with JasperReports.
>
> More importantly to me, if I decide to drop JasperReports and move to
> something else later, it won't be very difficult.
>
> I am sure Hans integration of Birt would be very useful for those who use
> Birt, and I expect they appreciate his effort. If Birt was in Extras,
> perhaps some of those people would be more likely to contribute to its
> maintenance.
>
> Cheers,
> Anne.
>
> On 23 March 2012 01:37, Mansour Al Akeel <ma...@gmail.com> wrote:
>
>> I don't know why birt is integrated with Ofbiz. A reporting tools, is
>> an add-on to any database driven system, and not essential for the
>> over all functionality. Yes all of us need reports, and most of the
>> time we use a reporting engine, but why can't it be separated from the
>> code base, and used as a separate application ?
>>
>> From my perspective, the core should contain only components needed to
>> bring it up to a functional state. Entity Engine, Service Engine, fall
>> under this category. Some may argue that UI should be considered as
>> well, and this is valid argument. But when it comes to reporting
>> engine, I don't think so.
>>
>>
>>
>> On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES
>> <er...@nereide.fr> 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.
>> >>
>> >> 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
>> >>
>> >> 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 ?
>> > Also, creating more of those reports (with not available features in
>> FOP),
>> > will this go in the right way to keep it there ?
>> >
>> >
>> > --
>> > Erwan de FERRIERES
>> > www.nereide.biz
>>
>
>
>
> --
> 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: sales@cohsoft.com.au
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Anne <an...@cohsoft.com.au>.
+1 to Mansour's comments.
I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and
Groovy I currently
>> 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.
(points are from Hans earlier email, though maybe my idea of "fully
integrate" isn't the same as Hans). I presume I can also incorporate the
warehouse entities, and use minilang (Hans' other two points), though I
haven't yet tried either. Maybe it is easier to do these things with Birt,
but I don't have any difficulty with JasperReports.
More importantly to me, if I decide to drop JasperReports and move to
something else later, it won't be very difficult.
I am sure Hans integration of Birt would be very useful for those who use
Birt, and I expect they appreciate his effort. If Birt was in Extras,
perhaps some of those people would be more likely to contribute to its
maintenance.
Cheers,
Anne.
On 23 March 2012 01:37, Mansour Al Akeel <ma...@gmail.com> wrote:
> I don't know why birt is integrated with Ofbiz. A reporting tools, is
> an add-on to any database driven system, and not essential for the
> over all functionality. Yes all of us need reports, and most of the
> time we use a reporting engine, but why can't it be separated from the
> code base, and used as a separate application ?
>
> From my perspective, the core should contain only components needed to
> bring it up to a functional state. Entity Engine, Service Engine, fall
> under this category. Some may argue that UI should be considered as
> well, and this is valid argument. But when it comes to reporting
> engine, I don't think so.
>
>
>
> On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES
> <er...@nereide.fr> 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.
> >>
> >> 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
> >>
> >> 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 ?
> > Also, creating more of those reports (with not available features in
> FOP),
> > will this go in the right way to keep it there ?
> >
> >
> > --
> > Erwan de FERRIERES
> > www.nereide.biz
>
--
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: sales@cohsoft.com.au
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Mansour Al Akeel <ma...@gmail.com>.
I don't know why birt is integrated with Ofbiz. A reporting tools, is
an add-on to any database driven system, and not essential for the
over all functionality. Yes all of us need reports, and most of the
time we use a reporting engine, but why can't it be separated from the
code base, and used as a separate application ?
>From my perspective, the core should contain only components needed to
bring it up to a functional state. Entity Engine, Service Engine, fall
under this category. Some may argue that UI should be considered as
well, and this is valid argument. But when it comes to reporting
engine, I don't think so.
On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES
<er...@nereide.fr> 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.
>>
>> 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
>>
>> 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 ?
> Also, creating more of those reports (with not available features in FOP),
> will this go in the right way to keep it there ?
>
>
> --
> Erwan de FERRIERES
> www.nereide.biz
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Erwan de FERRIERES <er...@nereide.fr>.
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.
>
> 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
>
> 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 ?
Also, creating more of those reports (with not available features in
FOP), will this go in the right way to keep it there ?
--
Erwan de FERRIERES
www.nereide.biz
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Nicolas Malin <ma...@librenberry.net>.
Le 22/03/2012 04:47, Hans Bakker a écrit :
> Hi Anne,
>
> Birt has several advantages in the current integration and we use it
> often on the warehouse entities. These entities are mostly not in the
> BI component but in the application components.
>
> Jasper reports and all others do not use the ofbiz framework but work
> on the JDBC driver directly or even worse only work on mysql or are
> mostly commercial.
Just to correct this, Birt is integrate currently in OFBiz (and tks a
lot for the work :) ), but jasper to if you load the interface. By
default you can use JDBC driver with these tools, put all have an api to
integrate it. Last time we work on integration with open office, it's
just a data preparation by the technical interface. If Birt move on
extra, a goal will be the simplify integration between service engine
and report layer.
Nicolas
>
> Integration with Birt is using the ofbiz framework and works on any
> data base that ofbiz runs on.
>
> Regards,
> Hans
>
>
> With BI i mean the BI screens/forms, not the entities.
>
> On 03/22/2012 09:47 AM, Anne wrote:
>> I thought Birt was a report generation/layout tool, like
>> JasperReports and
>> many others. I don't understand why it would have anything to do with
>> datawarehousing.
>>
>> I agree with Hans that datawarehousing is important. But I think that
>> should be part of BI, or other (possibly framework) functionality not
>> tied
>> to presentation.
>>
>> With the single exception of point 5, aren't the listed positives all
>> related to non-Birt functionality? Birt just manages the
>> presentation? And
>> point 5 could be handled by competitors to Birt?
>>
>> Cheers,
>> Anne.
>>
>> On 22 March 2012 12:38, Hans Bakker<ma...@antwebsystems.com>
>> wrote:
>>
>>> 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.
>>>
>>> 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
>>>
>>> I very strongly think about keeping this in the framework.
>>>
>>> BI component I agree, can go....
>>>
>>> Regards,
>>> Hans
>>>
>>>
>>>
>>> On 03/20/2012 06:47 PM, Jacopo Cappellato wrote:
>>>
>>>> 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
>>>>
>>>
>>
>
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Hans Bakker <ma...@antwebsystems.com>.
Hi Anne,
Birt has several advantages in the current integration and we use it
often on the warehouse entities. These entities are mostly not in the BI
component but in the application components.
Jasper reports and all others do not use the ofbiz framework but work on
the JDBC driver directly or even worse only work on mysql or are mostly
commercial.
Integration with Birt is using the ofbiz framework and works on any data
base that ofbiz runs on.
Regards,
Hans
With BI i mean the BI screens/forms, not the entities.
On 03/22/2012 09:47 AM, Anne wrote:
> I thought Birt was a report generation/layout tool, like JasperReports and
> many others. I don't understand why it would have anything to do with
> datawarehousing.
>
> I agree with Hans that datawarehousing is important. But I think that
> should be part of BI, or other (possibly framework) functionality not tied
> to presentation.
>
> With the single exception of point 5, aren't the listed positives all
> related to non-Birt functionality? Birt just manages the presentation? And
> point 5 could be handled by competitors to Birt?
>
> Cheers,
> Anne.
>
> On 22 March 2012 12:38, Hans Bakker<ma...@antwebsystems.com> wrote:
>
>> 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.
>>
>> 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
>>
>> I very strongly think about keeping this in the framework.
>>
>> BI component I agree, can go....
>>
>> Regards,
>> Hans
>>
>>
>>
>> On 03/20/2012 06:47 PM, Jacopo Cappellato wrote:
>>
>>> 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
>>>
>>
>
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Anne <an...@cohsoft.com.au>.
I thought Birt was a report generation/layout tool, like JasperReports and
many others. I don't understand why it would have anything to do with
datawarehousing.
I agree with Hans that datawarehousing is important. But I think that
should be part of BI, or other (possibly framework) functionality not tied
to presentation.
With the single exception of point 5, aren't the listed positives all
related to non-Birt functionality? Birt just manages the presentation? And
point 5 could be handled by competitors to Birt?
Cheers,
Anne.
On 22 March 2012 12:38, Hans Bakker <ma...@antwebsystems.com> wrote:
> 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.
>
> 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
>
> I very strongly think about keeping this in the framework.
>
> BI component I agree, can go....
>
> Regards,
> Hans
>
>
>
> On 03/20/2012 06:47 PM, Jacopo Cappellato wrote:
>
>> 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: sales@cohsoft.com.au
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Hans Bakker <ma...@antwebsystems.com>.
sure...but then i do not understand your comment...where do i indicate
there is a dependency from the framework on an application? Warehouse
entities are stored in the application?
On 03/22/2012 06:14 PM, Jacques Le Roux wrote:
> I mean the framework should know nothing about applications
>
>>>> 6. Incorporates the warehouse entities.
>
>
> Jacques
>
> From: "Hans Bakker" <ma...@antwebsystems.com>
>> dependencies from applications to Birt in the framework?
>> sure because Birt is part of the framework.....
>>
>> warehouse entities and reports on them belong to the applications,
>> not to the birt application.
>>
>> Regards,
>> Hans
>>
>> On 03/22/2012 05:11 PM, Jacques Le Roux wrote:
>>> From your remarks it seems then that it introduces dependencies from
>>> applications. This is a part of what we are trying to avoid
>>>
>>> Jacques
>>>
>>> Hans Bakker wrote:
>>>> 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.
>>>>
>>>> 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
>>>>
>>>> I very strongly think about keeping this in the framework.
>>>>
>>>> BI component I agree, can go....
>>>>
>>>> Regards,
>>>> Hans
>>>>
>>>>
>>>> On 03/20/2012 06:47 PM, Jacopo Cappellato wrote:
>>>>>> 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
>>
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Jacques Le Roux <ja...@les7arts.com>.
I mean the framework should know nothing about applications
>>> 6. Incorporates the warehouse entities.
Jacques
From: "Hans Bakker" <ma...@antwebsystems.com>
> dependencies from applications to Birt in the framework?
> sure because Birt is part of the framework.....
>
> warehouse entities and reports on them belong to the applications, not
> to the birt application.
>
> Regards,
> Hans
>
> On 03/22/2012 05:11 PM, Jacques Le Roux wrote:
>> From your remarks it seems then that it introduces dependencies from
>> applications. This is a part of what we are trying to avoid
>>
>> Jacques
>>
>> Hans Bakker wrote:
>>> 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.
>>>
>>> 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
>>>
>>> I very strongly think about keeping this in the framework.
>>>
>>> BI component I agree, can go....
>>>
>>> Regards,
>>> Hans
>>>
>>>
>>> On 03/20/2012 06:47 PM, Jacopo Cappellato wrote:
>>>>> 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
>
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Hans Bakker <ma...@antwebsystems.com>.
dependencies from applications to Birt in the framework?
sure because Birt is part of the framework.....
warehouse entities and reports on them belong to the applications, not
to the birt application.
Regards,
Hans
On 03/22/2012 05:11 PM, Jacques Le Roux wrote:
> From your remarks it seems then that it introduces dependencies from
> applications. This is a part of what we are trying to avoid
>
> Jacques
>
> Hans Bakker wrote:
>> 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.
>>
>> 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
>>
>> I very strongly think about keeping this in the framework.
>>
>> BI component I agree, can go....
>>
>> Regards,
>> Hans
>>
>>
>> On 03/20/2012 06:47 PM, Jacopo Cappellato wrote:
>>>> 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
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Jacques Le Roux <ja...@les7arts.com>.
>From your remarks it seems then that it introduces dependencies from applications.
This is a part of what we are trying to avoid
Jacques
Hans Bakker wrote:
> 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.
>
> 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
>
> I very strongly think about keeping this in the framework.
>
> BI component I agree, can go....
>
> Regards,
> Hans
>
>
> On 03/20/2012 06:47 PM, Jacopo Cappellato wrote:
>>> 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
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Hans Bakker <ma...@antwebsystems.com>.
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.
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
I very strongly think about keeping this in the framework.
BI component I agree, can go....
Regards,
Hans
On 03/20/2012 06:47 PM, Jacopo Cappellato wrote:
>> 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
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Pierre Smits <pi...@gmail.com>.
Currently, rptdesign is used in specialpurpose applications like ebaystore
and scrum, but also in core applications (accounting, order and product).
We have to provide reports in our applications, as it would be difficult to
maintain the concept of completeness of functionality without them.
Endusers requirements always dictate some kind of reports in applications.
I prefer to have a working solution ootb in OFBiz. Birt delivers that at
the moment.
Removing it creates another proposition issue (on top of all the others we
can think of why OFBiz is hard to sell).
Replacing it by something else would dictate roadmapping.
Regards,
Pierre
Op 20 maart 2012 12:47 schreef Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> het volgende:
> >
> > 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
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Nicolas Malin <ma...@librenberry.net>.
Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
>> 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?
Currently, we work on a POC to use content for reporting, the report
mechanism is selected by the template type. We implement our first
reports with openoffice but I don't see blocking to use birt, jasper or
other. With this methods, all report engine can move on Extras and when
you deploy, you select for specific report the content thus the desired
engine.
My vision : by default Apache OFBiz embed Xsl-fo and when you download a
other report engine, it give some example and standard content reporting.
+1 to move birt in extras :)
> 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
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Olivier Heintz <ho...@nereide.biz>.
+1 birt to extra
and there will also a jasperReport in extras
Le 20/03/2012 15:34, Mansour Al Akeel a écrit :
> +1 birt to Extra.
>
>
> On Tue, Mar 20, 2012 at 10:31 AM,<ad...@sandglass-software.com> wrote:
>> 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.
>>
>> -Adrian
>>
>>
>> Quoting Jacopo Cappellato<ja...@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
>>
>>
>>
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Mansour Al Akeel <ma...@gmail.com>.
+1 birt to Extra.
On Tue, Mar 20, 2012 at 10:31 AM, <ad...@sandglass-software.com> wrote:
> 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.
>
> -Adrian
>
>
> Quoting Jacopo Cappellato <ja...@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
>
>
>
>
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Adrian Crum <ad...@sandglass-software.com>.
We could include a metadata interface that external reporting tools to
can use to generate reports.
-Adrian
On 4/3/2012 10:27 AM, Divesh Dutta wrote:
> +1 for Adrian.
>
> IT departments use specific tools. And they would like to integrate those tools with OFBiz. So any reporting tool should go in Extras and End User should download them as per their need. We just need good documentation around all these efforts to help end users.
>
> Thanks
> --
> Divesh
>
> On Mar 20, 2012, at 8:01 PM, adrian.crum@sandglass-software.com wrote:
>
>> 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.
>>
>> -Adrian
>>
>> Quoting Jacopo Cappellato<ja...@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
>>
>>
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Divesh Dutta <di...@hotwaxmedia.com>.
+1 for Adrian.
IT departments use specific tools. And they would like to integrate those tools with OFBiz. So any reporting tool should go in Extras and End User should download them as per their need. We just need good documentation around all these efforts to help end users.
Thanks
--
Divesh
On Mar 20, 2012, at 8:01 PM, adrian.crum@sandglass-software.com wrote:
> 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.
>
> -Adrian
>
> Quoting Jacopo Cappellato <ja...@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
>
>
>
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Anne <an...@cohsoft.com.au>.
+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 <ja...@les7arts.com>wrote:
> From: "Olivier Heintz" <ho...@nereide.biz>
>
> Le 20/03/2012 15:31, adrian.crum@sandglass-**software.com<ad...@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 <ja...@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: sales@cohsoft.com.au
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Olivier Heintz" <ho...@nereide.biz>
> Le 20/03/2012 15:31, adrian.crum@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 <ja...@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
>>
>>
>>
>>
>
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by Olivier Heintz <ho...@nereide.biz>.
Le 20/03/2012 15:31, adrian.crum@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.
>
> -Adrian
>
> Quoting Jacopo Cappellato <ja...@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
>
>
>
>
Re: Lose Weight Program for OFBiz - Birt and BI
Posted by ad...@sandglass-software.com.
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.
-Adrian
Quoting Jacopo Cappellato <ja...@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