I think of the BI stuff as being very like where we are going with
themes and portal and such. The framework has infrastructure and the
applications and such plugin to that infrastructure (through whatever
means make the most sense).
For BI that would mean all of the tools (including UI) go in the
framework, as long as they do not depend on anything in applications,
and that data and services and more custom UI and so on go in the
applications or specialpurpose components.
That will probably require splitting some of the POC stuff that Jacopo
did into different components...
-David
On Jan 23, 2009, at 4:42 PM, Jacopo Cappellato wrote:
I would really prefer to keep it in the framework and just move the
quickInitDataWarehouse (demo) service to somewhere else... any of
the existing applications' components would be fine.
Jacopo
On Jan 5, 2009, at 2:11 AM, Bruno Busco wrote:
I have read David's post and I understood that having BI in
specialpurpose was not correct because it is a core module for an
ERP.
From this I thought that having it in application could be ok and
still have the framework easily isolable.
-Bruno
2009/1/5 BJ Freeman <bjf...@free-man.net>:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I think if you read davids comments included, that is the reason.
Framework you can have dependencies on,
Application you can not have framework depend on applications.
Bruno Busco sent the following on 1/4/2009 1:48 PM:
Hi Jacopo,
I have moved the "bi" folder from the framework to
"application" (not
specialpurpose) and changed build.xml and component-load.xml.
It seems to me that it works well there.
Are there any specific reasons for having it in the framework
folder
and not moving to "application" folder?
Thank you,
-Bruno
2009/1/4 Jacopo Cappellato <jacopo.cappell...@hotwaxmedia.com>:
Hi Bruno,
these service calls are part of the quickInitDataWarehouse
method that is
just a util method to simplify the BI setup for demo purposes: I
know this
is not ideal and I agree that the method should be moved outside
of the
framework.
But maybe for now we could leave it as is and just add a comment
to it... it
is really useful in demos and testing.
Jacopo
On Dec 26, 2008, at 8:53 AM, Bruno Busco wrote:
That's fine,
we should then understand how to resolve some dependencies i.e.
service calls like:
<call-service service-
name="loadAllProductsInProductDimension"
in-map-name="inMap"/>
or
<call-service service-name="loadSalesInvoiceFact"
in-map-name="inMap"/>
that are defined in catalog and accounting components that (I
guess)
will not part of the framework.
-Bruno
2008/12/26 David E. Jones <david.jo...@hotwaxmedia.com>:
I think you misunderstand. The main bi stuff is just a tool,
and really
belongs in the framework. Built on top of those tools are OOTB
star
schema data models that can be used along with the OOTB
operational data
model. Those belong with the base applications, along with
reports that
are more generic in nature. Either way, most of the bi stuff
is core to
OFBiz, and an important part of it (especially the star-schema
and data
warehouse related parts), and is certainly not a peripheral
add-on as
being in specialpurpose would imply.
-David
Bruno Busco wrote:
But maybe is better to move files using SVN in order to
maintain
history...
2008/12/25 Bruno Busco <bruno.bu...@gmail.com>:
If needed I can send a patch for this right now.
2008/12/25 Bruno Busco <bruno.bu...@gmail.com>:
David,
I was trying to move the BI folder from framework to
specialpurpose
and, once changed the build.xml and component-load.xml files,
it seems to build and work well.
Could we move it in order to simplify the framework-only
deploy?
-Bruno
2008/12/25 David E. Jones <david.jo...@hotwaxmedia.com>:
The placement of BI in the diagram is based on the original
implementation, which was not part of the framework as it
is now. BI
is
kind of a funny one and while there are tools for BI in the
framework,
and base data structures within the base applications, it
can really
exist in applications, specialpurpose, or hot-deploy/add-on
components.
-David
Bruno Busco wrote:
Thank you David,
I did not see this page before and it helps very much.
I will take this as a Christmas present from you. ;-)
BTW, so this confirms that party should be out of the
framework and
we
should remove all dependences on it from the framework
(not adding
more).
Then I see that the BI also is out of the framework (and
this is ok)
but in my framework-only installation that I got deleting
the
applications and specialourpose folders from a full trunk
checkout
BI
is there but of couurse not working.
Could we think of moving BI files from framework to
specialpurpose
folder?
-Bruno
2008/12/25 David E Jones <david.jo...@hotwaxmedia.com>:
The decision has already been made, and even documented
(a miracle,
yes I
know). For details see:
http://docs.ofbiz.org/display/OFBADMIN/Component+and+Component+Set+Dependencies
Now we just need to stick to it... so thanks for
bringing this up
Bruno.
-David
On Dec 25, 2008, at 12:27 AM, Bruno Busco wrote:
Hi,
this change sets an additional dependence of the
framework from
the
Party application.
We should definitively take a decition on how to
separate the
framework.
-Bruno
2008/12/25 <hans...@apache.org>:
Author: hansbak
Date: Wed Dec 24 22:26:14 2008
New Revision: 729396
URL: http://svn.apache.org/viewvc?rev=729396&view=rev
Log:
OFBIZ-2097: show organizationPartyId in header(can be
set in
preferences), rewrote financial history to show
currencies,
invoice/p[aymentworker now can show in actual and
organizationparty currency
Added:
ofbiz/trunk/applications/party/webapp/partymgr/WEB-INF/
actions/party/UnAppliedInvoicesForParty.groovy
(with props)
ofbiz/trunk/applications/party/webapp/partymgr/WEB-INF/
actions/party/UnAppliedPaymentsForParty.groovy
(with props)
Modified:
ofbiz/trunk/applications/accounting/config/
AccountingUiLabels.xml
ofbiz/trunk/applications/accounting/entitydef/
entitymodel.xml
ofbiz/trunk/applications/accounting/src/org/ofbiz/
accounting/invoice/InvoiceWorker.java
ofbiz/trunk/applications/accounting/src/org/ofbiz/
accounting/payment/PaymentWorker.java
ofbiz/trunk/applications/accounting/webapp/accounting/
WEB-INF/actions/invoice/EditInvoice.groovy
ofbiz/trunk/applications/accounting/webapp/accounting/
invoice/InvoiceForms.xml
ofbiz/trunk/applications/accounting/webapp/accounting/
payment/PaymentForms.xml
ofbiz/trunk/applications/accounting/widget/
InvoiceScreens.xml
ofbiz/trunk/applications/accounting/widget/Menus.xml
ofbiz/trunk/applications/party/entitydef/entitymodel.xml
ofbiz/trunk/applications/party/webapp/partymgr/WEB-INF/
actions/party/PartyFinancialHistory.groovy
ofbiz/trunk/applications/party/webapp/partymgr/party/
PartyForms.xml
ofbiz/trunk/applications/party/widget/partymgr/
PartyScreens.xml
ofbiz/trunk/applications/party/widget/partymgr/
ProfileScreens.xml
ofbiz/trunk/framework/common/config/CommonUiLabels.xml
ofbiz/trunk/framework/common/webcommon/includes/
header.ftl
ofbiz/trunk/framework/common/widget/CommonScreens.xml
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJYV4OrP3NbaWWqE4RApKFAKCHbPfHV8qwnPhdUvVdO6OiGhuejACbBaQS
m2jKte9yyaZuQ3HEhoOpxwU=
=bFu4
-----END PGP SIGNATURE-----