Hi Ron and All, I like the structure you suggested below. Short, sweet and to the point. I suggest we name them as domains, not as components. So we follow the Data Model Resource Book and break the names into things like invoicing, workeffort, shipment, order, party, human-resources etc ... and not necessarily into component names.
Taher Alkhateeb ----- Original Message ----- From: "Ron Wheeler" <[email protected]> To: [email protected] Sent: Friday, 12 June, 2015 2:17:50 PM Subject: Re: Move Application Entity Definitions to A Separate Component It would be nice to get the philosophy of the structure agreed at the beginning even if there is only one variant of accounting-entitymodel.xml . It might prevent conflicts over the content of some of the files and encourage more contributors who are confident about how their definitions work but are unwilling to change someone else's working set of entities, to contribute their variants. For example, I could supply my idea of what the Canadian accounting-entitymodel.xml should contain without breaking something that others are using. An alternative scheme that might be easier to use would be to structure the files as entitydef/accounting-entitymodel.xml entitydef/ecommerce-entitymodel.xml entitydef/general/UK/accounting-entitymodel.xml entitydef/general/UK/ecommerce-entitymodel.xml I am not sure that adding applications/datamodel to the front adds any value entitydef is pretty unambiguous. Putting the variants first would mean that all of the default entity definitions are in one folder and general/UK would all be in another. To get a complete set, copy everything from entitydef and then copy everything from entitydef/general/UK to get the overrides required t create the UK variant. Ron On 12/06/2015 2:39 AM, Jacques Le Roux 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 >>> <[email protected]> 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 >>> >>> >>> >> >> > -- Ron Wheeler President Artifact Software Inc email: [email protected] skype: ronaldmwheeler phone: 866-970-2435, ext 102
