On Jun 12, 2015, at 8:45 AM, Pierre Smits <pierre.sm...@gmail.com> wrote:
> I don't agree that moving in this direction will convince our potential > adopters to chose OFBiz. Having all entities in one component doestn't give > them more choice. Neither does having all eecas in one component. > > Today it is already possible to have the entity definitions split up into > multiple files to create more clarity as to what each component delivers. > The same can be said for eecas and other services. Maybe we should embark > on that, before we decide to move it all to one monolithical entity > component. The files will be split into business domain areas, not different from now; the advantage is that the new component will make it easy to deploy a data model only system (framework + data model) for the ones interested in building custom applications on top of it. Currently you cannot deploy a subset of the data model (e.g. accounting) because the foreign key relationship between entities: the layout changes we are discussing will not make this worse or better... you could still remove an entity definition line in ofbiz-component.xml to disable some entities. Regards, Jacopo > > Best regards, > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > > On Fri, Jun 12, 2015 at 8:39 AM, Jacques Le Roux < > jacques.le.r...@les7arts.com> wrote: > >> Le 11/06/2015 21:10, Ron Wheeler a écrit : >> >>> I would suggest adding other levels to the structure so that >>> specializations are easy to add without creating conflicts or constant flux >>> as people alter the accounting-entitymodel.xml to suit their needs and >>> submit it as the "right" version". >>> >>> applications/datamodel/entitidef/accounting-entitymodel.xml >>> might be better structured as >>> applications/datamodel/entitidef/demo/accounting-entitymodel.xml >>> applications/datamodel/entitidef/general/accounting-entitymodel.xml >>> applications/datamodel/entitidef/manufacturing/accounting-entitymodel.xml >>> >>> applications/datamodel/entitidef/professionalServices/accounting-entitymodel.xml >>> applications/datamodel/entitidef/eCommerce/accounting-entitymodel.xml >>> >>> It may be that the first specialization will be by country or region to >>> get the vocabulary or regulatory compliance particularities separated >>> >>> applications/datamodel/entitidef/general/UK/accounting-entitymodel.xml >>> applications/datamodel/entitidef/general/NAFTA/accounting-entitymodel.xml >>> >>> applications/datamodel/entitidef/general/NAFTA_MX/accounting-entitymodel.xml >>> applications/datamodel/entitidef/general/EU/accounting-entitymodel.xml >>> >>> applications/datamodel/entitidef/demo/accounting-entitymodel.xml >>> applications/datamodel/entitidef/demo/EU/accounting-entitymodel.xml >>> applications/datamodel/entitidef/demo/NAFTA/accounting-entitymodel.xml >>> >>> applications/datamodel/entitidef/manufacturing/EU/accounting-entitymodel.xml >>> >>> applications/datamodel/entitidef/professionalServices/EU?accounting-entitymodel.xml >>> applications/datamodel/entitidef/eCommerce/EU/accounting-entitymodel.xml >>> >>> Clearly we would start out with only the demo set but I think that we >>> could quickly get some of the other alternatives in place as people >>> contribute versions that they want to be part of the basic set. >>> >>> Would it make sense to break accounting-entitymodel.xml into separate >>> files for mandatory and optional entities to make it clear the entities >>> that can be modified or dropped without affecting OOB functionality? >>> >> >> I'm not against the idea, though it needs to be discussed more >> Anyway it can be done later as we will go with baby steps as Jacopo >> suggested >> >> Jacques >> >> >> >>> Ron >>> >>> >>> On 11/06/2015 10:18 AM, Jacopo Cappellato wrote: >>> >>>> On Jun 11, 2015, at 3:51 PM, Taher Alkhateeb <slidingfilame...@gmail.com> >>>> wrote: >>>> >>>> I would like to help and I think we need to think carefully of the >>>>> layout / structure though i.e. how to breakup the entities in files and/or >>>>> directories. >>>>> >>>> I would suggest that, at least in the first step, we do it in a simple >>>> way like the following: >>>> >>>> 1) create the new component, named for example "datamodel" (please >>>> suggest a better name) >>>> 2) move all the entity xml files from the applications to the >>>> "datamodel" component keeping the files separated as they are, but adding a >>>> prefix; for example >>>> >>>> applications/accounting/entitidef/entitymodel.xml >>>> >>>> will be moved to: >>>> >>>> applications/datamodel/entitidef/accounting-entitymodel.xml >>>> >>>> The end result will be a "datamodel" component with an entitidef/ folder >>>> containing several files, approximately one per application component >>>> >>>> 3) similar approach for eeca files >>>> >>>> 4) add the relevant entries in >>>> >>>> applications/datamodel/ofbiz-component.xml >>>> >>>> Regards, >>>> >>>> Jacopo >>>> >>>> >>>> >>>> >>> >>>
