This is related to this concept
http://docs.ofbiz.org/display/OFBTECH/General+Entity+Overview#GeneralEntityOverview-ExtensibilityPattern
Jacques
From: "BJ Freeman" <bjf...@free-man.net>
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 <bjf...@free-man.net> 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.
