On 14/06/2015 2:16 AM, Jacques Le Roux wrote:
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.
I meant locally unambiguous within the OFBiz source structure.
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.
I am trying to avoid a short term solution that makes a long-term
solution more difficult for no real reason. I am not sure how many
specialized entity definitions are stting on shelves today that could be
shared (either for free or as commercial offerings).
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)?
I was suggesting a scheme where the file names are identical but the
files come from different paths so the run-time situation would have no
duplication of file names but the files might come from different
sources (accounting-entitymodel.xml from
"entitydef/general/accounting-entitymodel.xml" being overwritten by
"entitydef/general/UK/accounting-entitymodel.xml" in the case where the
installation required the UK version of "accounting-entitymodel.xml"
This implies that all of the definitions in
entitydef/general/UK/accounting-entitymodel.xml are also in
entitydef/general/accounting-entitymodel.xml.
Ron
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
<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
