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
