Le 13/06/2015 14:12, Ron Wheeler a écrit :
a) I am not sure why applications/datamodel/entitidef/ could not be entitydef /
since it is shorter and unambiguous and spells entity correctly.
Applications was suggested because there are underneath mechanisms to handle the specialised folders framework, applications, specialpurpose and
hot-deploy (which is a confusing name, eg extensions would have been better)
Datamodel is a real unambiguous name, while entitydef is less (HTML entities?
etc.: https://en.wikipedia.org/wiki/Entity), this is a moot point.
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.
Jacopo's suggestion is straightforward. It's the 1st move we are currently discussing to agree on. Your propositon is interesting but to avoid
confusion should be discussed later, in another thread.
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
How to realise you idea needs to be discussed (again separately). A new mechanism might need to be created. In OFBiz a last read entity definition
overrides the previous . How to separate/aggregate is not obvious to me in your proposition. Did you think about optional entity extensions (defined
using the extend-entity mechanism) which would not be activated OOTB but could be loaded by users when needed (Oops, you see I'm already discussing
your proposition)?
Jacques
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 <[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
