You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Sharan-F <sh...@gmail.com> on 2015/06/11 09:46:56 UTC
Move Application Entity Definitions to A Separate Component
Hi All
I'd like to get some feedback on the a proposal Jacopo made a while ago to
find out if we have enough consenus to include it in our upcoming Community
Day.
*/Some time ago I proposed to move all entity definitions from the
applications components into a separate one; this component could also
contain crud/generic services: in this way it will be easier to deploy the
framework+data-model without the user interfaces that are not as generic and
universal as the data model is. In my opinion this would be a good step in
the right direction and it would be very easy to implement. /*
So my questions to you all are :
1. Can we reach a consenus as to whether or not we want to do it?
2. And if so, whether we want to include it as part of the work for our
Community Day next week?
Thanks
Sharan
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Move-Application-Entity-Definitions-to-A-Separate-Component-tp4669903.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Move Application Entity Definitions to A Separate Component
Posted by Nicolas Malin <ni...@nereide.fr>.
Le 11/06/2015 16:18, Jacopo Cappellato a écrit :
> On Jun 11, 2015, at 3:51 PM, Taher Alkhateeb <sl...@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)
applications/common-layer
applications/functional-layer
> 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
My preference goes to use the package path but add complexity for few. I
see :
applications/functional-layer/entitydef/model/entitymodel-accounting.xml
applications/functional-layer/entitydef/eca/eeca-accounting.xml
applications/functional-layer/servicedef/model/services-accounting.xml
applications/functional-layer/servicedef/eca/seca-accounting.xml
But currently some component already have multiple entitymodel file to
segment entities so why not :
applications/functional-layer/entitydef/model/accounting/entitymodel.xml
applications/functional-layer/entitydef/model/accounting/entitymodel-invoice.xml
applications/functional-layer/entitydef/model/accounting/entitymodel-payment.xml
applications/functional-layer/entitydef/eca/accounting/eeca.xml
>
> 3) similar approach for eeca files
>
> 4) add the relevant entries in
>
> applications/datamodel/ofbiz-component.xml
We can simplify entries with regexp like this
<entity-resource type="model" loader="main"
location="entitydef/model/*"/>
or just
<entity-resource type="model" loader="main"
dir-location="entitydef/model/accounting/"/>
Nicolas
>
> Regards,
>
> Jacopo
>
>
Re: Move Application Entity Definitions to A Separate Component
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On Jun 12, 2015, at 8:45 AM, Pierre Smits <pi...@gmail.com> wrote:
> I don't agree that moving in this direction will convince our potential
> adopters to chose OFBiz. Having all entities in one component doestn't give
> them more choice. Neither does having all eecas in one component.
>
> Today it is already possible to have the entity definitions split up into
> multiple files to create more clarity as to what each component delivers.
> The same can be said for eecas and other services. Maybe we should embark
> on that, before we decide to move it all to one monolithical entity
> component.
The files will be split into business domain areas, not different from now; the advantage is that the new component will make it easy to deploy a data model only system (framework + data model) for the ones interested in building custom applications on top of it.
Currently you cannot deploy a subset of the data model (e.g. accounting) because the foreign key relationship between entities: the layout changes we are discussing will not make this worse or better... you could still remove an entity definition line in ofbiz-component.xml to disable some entities.
Regards,
Jacopo
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Fri, Jun 12, 2015 at 8:39 AM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> 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 <sl...@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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
Re: Move Application Entity Definitions to A Separate Component
Posted by Ron Wheeler <rw...@artifact-software.com>.
I am not sure that restructuring the folder and separating the
definitions mean that we have to consolidate all accounting entities
into one file but separating code from data is the core of this idea.
Ron
On 12/06/2015 2:45 AM, Pierre Smits wrote:
> I don't agree that moving in this direction will convince our potential
> adopters to chose OFBiz. Having all entities in one component doestn't give
> them more choice. Neither does having all eecas in one component.
>
> Today it is already possible to have the entity definitions split up into
> multiple files to create more clarity as to what each component delivers.
> The same can be said for eecas and other services. Maybe we should embark
> on that, before we decide to move it all to one monolithical entity
> component.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Fri, Jun 12, 2015 at 8:39 AM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> 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 <sl...@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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Move Application Entity Definitions to A Separate Component
Posted by Pierre Smits <pi...@gmail.com>.
I don't agree that moving in this direction will convince our potential
adopters to chose OFBiz. Having all entities in one component doestn't give
them more choice. Neither does having all eecas in one component.
Today it is already possible to have the entity definitions split up into
multiple files to create more clarity as to what each component delivers.
The same can be said for eecas and other services. Maybe we should embark
on that, before we decide to move it all to one monolithical entity
component.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Fri, Jun 12, 2015 at 8:39 AM, Jacques Le Roux <
jacques.le.roux@les7arts.com> 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 <sl...@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
>>>
>>>
>>>
>>>
>>
>>
Re: Move Application Entity Definitions to A Separate Component
Posted by Ron Wheeler <rw...@artifact-software.com>.
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
>>>>>>> <sl...@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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Move Application Entity Definitions to A Separate Component
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <sl...@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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Move Application Entity Definitions to A Separate Component
Posted by Pierre Smits <pi...@gmail.com>.
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 <rw...@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 <
>>>>>> slidingfilaments@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: rwheeler@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
Re: Move Application Entity Definitions to A Separate Component
Posted by Ron Wheeler <rw...@artifact-software.com>.
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
>>>>> <sl...@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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Move Application Entity Definitions to A Separate Component
Posted by Nicolas Malin <ni...@nereide.fr>.
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
>>>> <sl...@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
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
Re: Move Application Entity Definitions to A Separate Component
Posted by Taher Alkhateeb <sl...@gmail.com>.
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" <rw...@artifact-software.com>
To: dev@ofbiz.apache.org
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
>>> <sl...@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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Move Application Entity Definitions to A Separate Component
Posted by Ron Wheeler <rw...@artifact-software.com>.
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
>>> <sl...@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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Move Application Entity Definitions to A Separate Component
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <sl...@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
>>
>>
>>
>
>
Re: Move Application Entity Definitions to A Separate Component
Posted by Ron Wheeler <rw...@artifact-software.com>.
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?
Ron
On 11/06/2015 10:18 AM, Jacopo Cappellato wrote:
> On Jun 11, 2015, at 3:51 PM, Taher Alkhateeb <sl...@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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Move Application Entity Definitions to A Separate Component
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 11/06/2015 16:18, Jacopo Cappellato a écrit :
> On Jun 11, 2015, at 3:51 PM, Taher Alkhateeb <sl...@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
This will indeed make the files more easy to find (though I generally look for entities not files)
>
> 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
I like the idea of having the eeca files more visible
BTW, for those interest this discussion began here https://cwiki.apache.org/confluence/display/OFBIZ/Roadmap+Diagrams+-+In+Progress
Jacques
>
> 4) add the relevant entries in
>
> applications/datamodel/ofbiz-component.xml
>
> Regards,
>
> Jacopo
>
>
>
>
Re: Move Application Entity Definitions to A Separate Component
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On Jun 11, 2015, at 3:51 PM, Taher Alkhateeb <sl...@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
Re: Move Application Entity Definitions to A Separate Component
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Sharan,
+1
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 think too much structure is painful to maintain and too little is overwhelming to navigate through. Perhaps we can categorize in a similar fashion to the data model resource book ToC.
Overall this would be a good first step to reduce component dependency
Taher Alkhateeb
----- Original Message -----
From: "Ron Wheeler" <rw...@artifact-software.com>
To: dev@ofbiz.apache.org
Sent: Thursday, 11 June, 2015 3:37:51 PM
Subject: Re: Move Application Entity Definitions to A Separate Component
+1
Would like to see the definitions organized in a way that makes it easy
to see what entities are mandatory "as is" as opposed to customizable.
Might also want to consider having multiple variations of the entities
to support different industries, different management focuses or languages.
These could be contributed by users and maintained by users rather than
developers.
Ron
On 11/06/2015 3:46 AM, Sharan-F wrote:
> Hi All
>
> I'd like to get some feedback on the a proposal Jacopo made a while ago to
> find out if we have enough consenus to include it in our upcoming Community
> Day.
>
> */Some time ago I proposed to move all entity definitions from the
> applications components into a separate one; this component could also
> contain crud/generic services: in this way it will be easier to deploy the
> framework+data-model without the user interfaces that are not as generic and
> universal as the data model is. In my opinion this would be a good step in
> the right direction and it would be very easy to implement. /*
>
> So my questions to you all are :
>
> 1. Can we reach a consenus as to whether or not we want to do it?
> 2. And if so, whether we want to include it as part of the work for our
> Community Day next week?
>
> Thanks
> Sharan
>
>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Move-Application-Entity-Definitions-to-A-Separate-Component-tp4669903.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Move Application Entity Definitions to A Separate Component
Posted by Ron Wheeler <rw...@artifact-software.com>.
+1
Would like to see the definitions organized in a way that makes it easy
to see what entities are mandatory "as is" as opposed to customizable.
Might also want to consider having multiple variations of the entities
to support different industries, different management focuses or languages.
These could be contributed by users and maintained by users rather than
developers.
Ron
On 11/06/2015 3:46 AM, Sharan-F wrote:
> Hi All
>
> I'd like to get some feedback on the a proposal Jacopo made a while ago to
> find out if we have enough consenus to include it in our upcoming Community
> Day.
>
> */Some time ago I proposed to move all entity definitions from the
> applications components into a separate one; this component could also
> contain crud/generic services: in this way it will be easier to deploy the
> framework+data-model without the user interfaces that are not as generic and
> universal as the data model is. In my opinion this would be a good step in
> the right direction and it would be very easy to implement. /*
>
> So my questions to you all are :
>
> 1. Can we reach a consenus as to whether or not we want to do it?
> 2. And if so, whether we want to include it as part of the work for our
> Community Day next week?
>
> Thanks
> Sharan
>
>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Move-Application-Entity-Definitions-to-A-Separate-Component-tp4669903.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102