Are we still talking about entity definitions? I would like to see where the universal data model misses elements regarding any locale.
Best regards, Pierre On Saturday, June 13, 2015, Ron Wheeler <rwhee...@artifact-software.com> wrote: > a) I am not sure why applications/datamodel/entitidef/ could not be > entitydef/ since it is shorter and unambiguous and spells entity correctly. > b) I thought that hot-deploy was for local customizations. "entitydef/..." > are user contributed libraries that are part of the standard OFBiz project > to support industry-specific or locale-specific requirements. > c) I am suggesting a structure that makes it easy for someone customizing > their implementation. Take all the xml files under entitydef ( or > entitydef/default or entity/basic) and overwrite them with the set of XML > files suitable for the particular locale that you want such as > entitydef/eCommerce/NAFTA to get the definitions that match an eCommerce > site in North America US and Canada terminology and the extensions or > modifications required to support an eCommerce-only OFBiz aimed at a North > American clientele. > If the system integrator does further customization and wants to put their > branding or customer-specific overrides in hot-deploy at run-time to keep > them separate from the XML files that come from OFBiz, that sounds like a > good practice but is different from the shared library structure we are > discussing. > > Does that clarify my points? > > Ron > > > > On 12/06/2015 9:51 AM, Nicolas Malin wrote: > >> Ron I didn't understand why you want adding specialization directory >> directly on main component (like entitydef/general/UK/). >> >> For me this information need to be set on the dedicate component in >> hot-deploy. >> >> Nicolas >> >> Le 12/06/2015 13:17, Ron Wheeler a écrit : >> >>> 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 < >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > -- Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com
