to give an example take a look at ContactMechTypeAttr in ofbiz this is an entity. the name says it is an attribute. entity in ofbiz is more a storage layout.
BJ Freeman sent the following on 5/6/2009 3:55 PM: > yes by the modeling book these are attributes > but I see they are actual entities in ofbiz. > The confusion I believe is What ofbiz calls an entity is not exactly > what the modeling book calls a entity. > you can see this in other Attributes/entities. > There is nothing keeping you from creating you own ofbiz entity. > if you want it to be accepted into the trunk then make you case and see > if it accepted. > what type of info did you have in mind? > > Cimballi sent the following on 5/6/2009 3:42 PM: >> BJ, my problem is not to store several emails, but to overload the "email >> informations entity". I would like to store the email address plus other >> informations. And it would be easy to do if there was an ElectronicAddress >> entity, but it's not the case (or I didn't find it, but I don't think so >> because in the demo data the email address is in the infoString field of a >> ContactMech). >> >> Cimballi >> >> >> On Wed, May 6, 2009 at 5:37 PM, BJ Freeman <[email protected]> wrote: >> >>> look at the contactmechtype for different types of electroninc addresses >>> it is a one to many >>> >>> BJ Freeman sent the following on 5/6/2009 3:34 PM: >>>> there is information about a contact which is in the contact mech. >>>> email is under electronic Address. >>>> >>>> then there is the event of the actual communications which you will find >>>> under communication event modeling. >>>> >>>> Cimballi sent the following on 5/6/2009 2:47 PM: >>>>> Hi, >>>>> >>>>> I was wondering was you didn't model the Email informations like Phone >>>>> informations in ContactMech. >>>>> Why is there no entity that model an Email, like the TelecomNumber >>> entity ? >>>>> My problem is, if I want to add another field to an Email informations, >>> the >>>>> possibilities are : >>>>> - extending the ContactMech class, but it's not optimum because this >>> class >>>>> is used for a lot of other informations than Email >>>>> - add a ContactMechAttribute related to the ContactMech entity >>> representing >>>>> the Email informations, but this imply more work to maintain the >>> relation >>>>> It would have been a lot easier to have an ElectronicAddress entity, no >>> ? >>>>> Cimballi >>>>> >>> -- >>> BJ Freeman >>> http://www.businessesnetwork.com/automation >>> http://bjfreeman.elance.com >>> >>> http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro >>> Systems Integrator. >>> >>> > -- BJ Freeman http://www.businessesnetwork.com/automation http://bjfreeman.elance.com http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro Systems Integrator.
