ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Malin <nicolas.ma...@nereide.fr>
Subject Re: Move Application Entity Definitions to A Separate Component
Date Fri, 12 Jun 2015 13:51:19 GMT
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
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>


Mime
View raw message