You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adam Heath <do...@brainfood.com> on 2010/02/01 22:23:51 UTC
ContactMechPurposeType bad design
There is currently a PRIMARY_EMAIL, PRIMARY_LOCATION, BILLING_EMAIL,
BILLING_LOCATION, etc. Why can't that just be PRIMARY, BILLING, etc?
Re: ContactMechPurposeType bad design
Posted by Adam Heath <do...@brainfood.com>.
Cimballi wrote:
> Not sure about the original idea, but from my point of view this helps
> to know what kind of contact mech is behind the purpose type.
> For example, if you have a party and you want to get its primary email
> contact mech, you search for PRIMARY_EMAIL and you know you will have
> only emails (well, if you didn't mess up everything... :-).
> If it was only PRIMARY, it could be any kind of contact mech, you
> would then have to go through the list to retrieve the contact mech of
> type email.
There is a view to handle that.
>
> Maybe another solution would be to have hierarchical types, so you
> would have PRIMARY and a child PRIMARY_EMAIL, and looking for PRIMARY
> would return PRIMARY and PRIMARY_EMAIL.
PRIMARY_EMAIL and PRIMARY_LOCATION are not normalized. You know it is
already an EMAIL_ADDRESS or a POSTAL_ADDRESS, by looking at the
associated ContactMech.contactMechTypeId field.
Re: ContactMechPurposeType bad design
Posted by Nicolas Malin <ma...@librenberry.net>.
Cimballi a écrit :
> Not sure about the original idea, but from my point of view this helps
> to know what kind of contact mech is behind the purpose type.
> For example, if you have a party and you want to get its primary email
> contact mech, you search for PRIMARY_EMAIL and you know you will have
> only emails (well, if you didn't mess up everything... :-).
> If it was only PRIMARY, it could be any kind of contact mech, you
> would then have to go through the list to retrieve the contact mech of
> type email.
>
You right if you want find information from ContactMechPurposeType but
the Type information is also present on ContactMech by contactMechTypeId
and you can find this with entityview
> Maybe another solution would be to have hierarchical types, so you
> would have PRIMARY and a child PRIMARY_EMAIL, and looking for PRIMARY
> would return PRIMARY and PRIMARY_EMAIL.
>
> HTH,
>
> Cimballi
>
>
> On Mon, Feb 1, 2010 at 4:23 PM, Adam Heath <do...@brainfood.com> wrote:
>
>> There is currently a PRIMARY_EMAIL, PRIMARY_LOCATION, BILLING_EMAIL,
>> BILLING_LOCATION, etc. Why can't that just be PRIMARY, BILLING, etc?
>>
>>
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
Re: ContactMechPurposeType bad design
Posted by Cimballi <ci...@gmail.com>.
Not sure about the original idea, but from my point of view this helps
to know what kind of contact mech is behind the purpose type.
For example, if you have a party and you want to get its primary email
contact mech, you search for PRIMARY_EMAIL and you know you will have
only emails (well, if you didn't mess up everything... :-).
If it was only PRIMARY, it could be any kind of contact mech, you
would then have to go through the list to retrieve the contact mech of
type email.
Maybe another solution would be to have hierarchical types, so you
would have PRIMARY and a child PRIMARY_EMAIL, and looking for PRIMARY
would return PRIMARY and PRIMARY_EMAIL.
HTH,
Cimballi
On Mon, Feb 1, 2010 at 4:23 PM, Adam Heath <do...@brainfood.com> wrote:
> There is currently a PRIMARY_EMAIL, PRIMARY_LOCATION, BILLING_EMAIL,
> BILLING_LOCATION, etc. Why can't that just be PRIMARY, BILLING, etc?
>
Re: ContactMechPurposeType bad design
Posted by Ruth Hoffman <rh...@aesolves.com>.
Hi Hans:
Yes, this is used in other places.
What exactly do you mean by "change"?
Regards,
Ruth
Hans Bakker wrote:
> If we change that and can still select a "primary email" then that
> sounds pretty good...however isn't this often used in the system?
>
> On Mon, 2010-02-01 at 15:23 -0600, Adam Heath wrote:
>
>> There is currently a PRIMARY_EMAIL, PRIMARY_LOCATION, BILLING_EMAIL,
>> BILLING_LOCATION, etc. Why can't that just be PRIMARY, BILLING, etc?
>>
Re: ContactMechPurposeType bad design
Posted by Hans Bakker <ma...@antwebsystems.com>.
If we change that and can still select a "primary email" then that
sounds pretty good...however isn't this often used in the system?
On Mon, 2010-02-01 at 15:23 -0600, Adam Heath wrote:
> There is currently a PRIMARY_EMAIL, PRIMARY_LOCATION, BILLING_EMAIL,
> BILLING_LOCATION, etc. Why can't that just be PRIMARY, BILLING, etc?
--
Antwebsystems.com: Quality OFBiz services for competitive rates