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
+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
--
Dives
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
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 b
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 wrote:
> Just for the record, we disable the birt container. I don't like loading
> thi
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 wrote:
> in the config for base:
>
> base/config/ofbiz-containers.xml:
> base/config/ofbiz-containers.xml: class="org.ofbiz.bi
in the config for base:
base/config/ofbiz-containers.xml:
base/config/ofbiz-containers.xml:
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
+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
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
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 integrationas
>> any component sure there is room for improvement however
>>
>> Some positives you did not even no
Le 22/03/2012 02:38, Hans Bakker a écrit :
Jacopo,
you are making here a very negative review of the Birt integrationas
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
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. I
I mean the framework should know nothing about applications
6. Incorporates the warehouse entities.
Jacques
From: "Hans Bakker"
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 app
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
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 integrationas
any component sure there is room for improvement however
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 fr
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 directl
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
Jacopo,
you are making here a very negative review of the Birt integrationas
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.
+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 wrote:
> From: "Olivier Heintz"
>
> Le 20/03/2012 15:31,
> adrian.crum@sandglass-**software.coma
From: "Olivier Heintz"
Le 20/03/2012 15:31, adrian.c...@sandglass-software.com a écrit :
I like the idea of keeping reporting tools separate from OFBiz. In my experience, IT departments are already using a reporting
tool for other applications and they would prefer to integrate that tool with O
+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, wrote:
I like the idea of keeping reporting tools separate from OFBiz. In my
experience, IT departments are already using a report
Le 20/03/2012 15:31, adrian.c...@sandglass-software.com a écrit :
I like the idea of keeping reporting tools separate from OFBiz. In my
experience, IT departments are already using a reporting tool for
other applications and they would prefer to integrate that tool with
OFBiz, instead of learni
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.
Endus
+1 birt to Extra.
On Tue, Mar 20, 2012 at 10:31 AM, 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 learn
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
Quoti
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 disagreeme
>
> 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
28 matches
Mail list logo