You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by BJ Freeman <bj...@free-man.net> on 2008/07/26 18:56:55 UTC
Postal Address entity
the databook figure 2.8 has it the way I figure it should be.
is there a reason it was implemented the way it was.
1) postaladdress has party information
2) it has Postal Code instead of being in the geography boundary
the motivation is to move forward on
http://docs.ofbiz.org/display/OFBIZ/Extending+PostalAddress+Information
the address Details
Re: Postal Address entity
Posted by BJ Freeman <bj...@free-man.net>.
I am glad to spend the time to show what has to be done, and even that I
will do it.
David E Jones sent the following on 7/26/2008 1:54 PM:
>
> If you want to make a serious proposal about removing those fields
> you'll have to look at their current use and propose alternatives. I
> mention this because I don't get the feeling that you understand what
> sort of impact this would have. For example right now we don't require a
> Geo record for every postal code used in the system, but if we did this
> it would be necessary.
>
> -David
>
>
> On Jul 26, 2008, at 12:07 PM, BJ Freeman wrote:
>
>> the Postal Address in the data book
>> has:
>> address1
>> address1
>> and
>> directions.
>>
>> the postaladdress entity has:
>> toName name
>> attnName name
>>
>> which to me should be using the postaladdress to PartyContactMech only
>>
>>
>> these should be removed
>> postalCode short-varchar
>> postalCodeExt short-varchar
>> and just use the
>> <field name="postalCodeGeoId" type="id"></field>
>> which would point to a entity Postalcode with a one to many (parent to
>> child) would point to postalCodeLine with a one to many (parent to
>> child)
>> The reasoning for the refactor is the would like to change the
>> PostalAddress to point to a new Entity Address line
>> with a one to many (parent to child) relation
>> it would have a sequence number for getting the proper output.
>> this would allow flexibility that is used in other countries.
>> the Postal address would also point to new entity AddressDirections
>>
>>
>> David E Jones sent the following on 7/26/2008 10:16 AM:
>>>
>>> On Jul 26, 2008, at 10:56 AM, BJ Freeman wrote:
>>>
>>>> the databook figure 2.8 has it the way I figure it should be.
>>>> is there a reason it was implemented the way it was.
>>>> 1) postaladdress has party information
>>>
>>> Could you be more specific?
>>>
>>>> 2) it has Postal Code instead of being in the geography boundary
>>>
>>> It actually has both.
>>>
>>> -David
>>>
>>>
>>>
>>>
>>
>
>
>
>
Re: Postal Address entity
Posted by David E Jones <jo...@hotwaxmedia.com>.
If you want to make a serious proposal about removing those fields
you'll have to look at their current use and propose alternatives. I
mention this because I don't get the feeling that you understand what
sort of impact this would have. For example right now we don't require
a Geo record for every postal code used in the system, but if we did
this it would be necessary.
-David
On Jul 26, 2008, at 12:07 PM, BJ Freeman wrote:
> the Postal Address in the data book
> has:
> address1
> address1
> and
> directions.
>
> the postaladdress entity has:
> toName name
> attnName name
>
> which to me should be using the postaladdress to PartyContactMech only
>
>
> these should be removed
> postalCode short-varchar
> postalCodeExt short-varchar
> and just use the
> <field name="postalCodeGeoId" type="id"></field>
> which would point to a entity Postalcode with a one to many (parent to
> child) would point to postalCodeLine with a one to many (parent to
> child)
> The reasoning for the refactor is the would like to change the
> PostalAddress to point to a new Entity Address line
> with a one to many (parent to child) relation
> it would have a sequence number for getting the proper output.
> this would allow flexibility that is used in other countries.
> the Postal address would also point to new entity AddressDirections
>
>
> David E Jones sent the following on 7/26/2008 10:16 AM:
>>
>> On Jul 26, 2008, at 10:56 AM, BJ Freeman wrote:
>>
>>> the databook figure 2.8 has it the way I figure it should be.
>>> is there a reason it was implemented the way it was.
>>> 1) postaladdress has party information
>>
>> Could you be more specific?
>>
>>> 2) it has Postal Code instead of being in the geography boundary
>>
>> It actually has both.
>>
>> -David
>>
>>
>>
>>
>
Re: Postal Address entity
Posted by BJ Freeman <bj...@free-man.net>.
sorry for the brain-fart
entitymodel.xsd
David E Jones sent the following on 7/26/2008 1:55 PM:
>
> What is the entity.xsd file?
>
> -David
>
>
> On Jul 26, 2008, at 1:29 PM, BJ Freeman wrote:
>
>> I also proposed a change to the entity.xsd that would put in output
>> format per field.
>> then the output would be drive by using output format
>> with what I proposed just in the address, only need to sort by the
>> sequence number to have correct line numbers
>> for input there would have to be an entity in country that gave the
>> address format
>>
>>
>> Adrian Crum sent the following on 7/26/2008 11:41 AM:
>>> As far as the UI is concerned, what about having an entity that ties
>>> a form widget name to a geo code? We could have something like
>>> CommonPostalAddressForms.xml that contains the various postal address
>>> layouts. Some work might need to be done in the form widget to give
>>> it the ability to include "form snippets."
>>>
>>> -Adrian
>>>
>>> --- On Sat, 7/26/08, BJ Freeman <bj...@free-man.net> wrote:
>>>
>>>> From: BJ Freeman <bj...@free-man.net>
>>>> Subject: Re: Postal Address entity
>>>> To: dev@ofbiz.apache.org
>>>> Date: Saturday, July 26, 2008, 11:31 AM
>>>> ooops
>>>> <field name="postalCodeGeoId"
>>>> type="id"></field>
>>>> which would point to a entity Postalcode with a one to one
>>>> would point to postalCodeLine with a one to one
>>>>
>>>>
>>>> BJ Freeman sent the following on 7/26/2008 11:07 AM:
>>>>> the Postal Address in the data book
>>>>> has:
>>>>> address1
>>>>> address1
>>>>> and
>>>>> directions.
>>>>>
>>>>> the postaladdress entity has:
>>>>> toName name
>>>>> attnName name
>>>>>
>>>>> which to me should be using the postaladdress to
>>>> PartyContactMech only
>>>>>
>>>>> these should be removed
>>>>> postalCode short-varchar
>>>>> postalCodeExt short-varchar
>>>>> and just use the
>>>>> <field name="postalCodeGeoId"
>>>> type="id"></field>
>>>>> which would point to a entity Postalcode with a one to
>>>> many (parent to
>>>>> child) would point to postalCodeLine with a one to
>>>> many (parent to child)
>>>>> The reasoning for the refactor is the would like to
>>>> change the
>>>>> PostalAddress to point to a new Entity Address line
>>>>> with a one to many (parent to child) relation
>>>>> it would have a sequence number for getting the proper
>>>> output.
>>>>> this would allow flexibility that is used in other
>>>> countries.
>>>>> the Postal address would also point to new entity
>>>> AddressDirections
>>>>>
>>>>> David E Jones sent the following on 7/26/2008 10:16
>>>> AM:
>>>>>> On Jul 26, 2008, at 10:56 AM, BJ Freeman wrote:
>>>>>>
>>>>>>> the databook figure 2.8 has it the way I
>>>> figure it should be.
>>>>>>> is there a reason it was implemented the way
>>>> it was.
>>>>>>> 1) postaladdress has party information
>>>>>> Could you be more specific?
>>>>>>
>>>>>>> 2) it has Postal Code instead of being in the
>>>> geography boundary
>>>>>> It actually has both.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>
Re: Postal Address entity
Posted by David E Jones <jo...@hotwaxmedia.com>.
What is the entity.xsd file?
-David
On Jul 26, 2008, at 1:29 PM, BJ Freeman wrote:
> I also proposed a change to the entity.xsd that would put in output
> format per field.
> then the output would be drive by using output format
> with what I proposed just in the address, only need to sort by the
> sequence number to have correct line numbers
> for input there would have to be an entity in country that gave the
> address format
>
>
> Adrian Crum sent the following on 7/26/2008 11:41 AM:
>> As far as the UI is concerned, what about having an entity that
>> ties a form widget name to a geo code? We could have something like
>> CommonPostalAddressForms.xml that contains the various postal
>> address layouts. Some work might need to be done in the form widget
>> to give it the ability to include "form snippets."
>>
>> -Adrian
>>
>> --- On Sat, 7/26/08, BJ Freeman <bj...@free-man.net> wrote:
>>
>>> From: BJ Freeman <bj...@free-man.net>
>>> Subject: Re: Postal Address entity
>>> To: dev@ofbiz.apache.org
>>> Date: Saturday, July 26, 2008, 11:31 AM
>>> ooops
>>> <field name="postalCodeGeoId"
>>> type="id"></field>
>>> which would point to a entity Postalcode with a one to one
>>> would point to postalCodeLine with a one to one
>>>
>>>
>>> BJ Freeman sent the following on 7/26/2008 11:07 AM:
>>>> the Postal Address in the data book
>>>> has:
>>>> address1
>>>> address1
>>>> and
>>>> directions.
>>>>
>>>> the postaladdress entity has:
>>>> toName name
>>>> attnName name
>>>>
>>>> which to me should be using the postaladdress to
>>> PartyContactMech only
>>>>
>>>> these should be removed
>>>> postalCode short-varchar
>>>> postalCodeExt short-varchar
>>>> and just use the
>>>> <field name="postalCodeGeoId"
>>> type="id"></field>
>>>> which would point to a entity Postalcode with a one to
>>> many (parent to
>>>> child) would point to postalCodeLine with a one to
>>> many (parent to child)
>>>> The reasoning for the refactor is the would like to
>>> change the
>>>> PostalAddress to point to a new Entity Address line
>>>> with a one to many (parent to child) relation
>>>> it would have a sequence number for getting the proper
>>> output.
>>>> this would allow flexibility that is used in other
>>> countries.
>>>> the Postal address would also point to new entity
>>> AddressDirections
>>>>
>>>> David E Jones sent the following on 7/26/2008 10:16
>>> AM:
>>>>> On Jul 26, 2008, at 10:56 AM, BJ Freeman wrote:
>>>>>
>>>>>> the databook figure 2.8 has it the way I
>>> figure it should be.
>>>>>> is there a reason it was implemented the way
>>> it was.
>>>>>> 1) postaladdress has party information
>>>>> Could you be more specific?
>>>>>
>>>>>> 2) it has Postal Code instead of being in the
>>> geography boundary
>>>>> It actually has both.
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>>
>>
>
Re: Postal Address entity
Posted by BJ Freeman <bj...@free-man.net>.
Yes. I agree. it would be a short term way of doing it.
see my next email on embedded format.
Adrian Crum sent the following on 7/26/2008 12:49 PM:
> I think my suggestion would accomplish both, without the need to change the xsd or have sequence numbers.
>
> -Adrian
>
> --- On Sat, 7/26/08, BJ Freeman <bj...@free-man.net> wrote:
>
>> From: BJ Freeman <bj...@free-man.net>
>> Subject: Re: Postal Address entity
>> To: dev@ofbiz.apache.org
>> Date: Saturday, July 26, 2008, 12:29 PM
>> I also proposed a change to the entity.xsd that would put in
>> output
>> format per field.
>> then the output would be drive by using output format
>> with what I proposed just in the address, only need to sort
>> by the
>> sequence number to have correct line numbers
>> for input there would have to be an entity in country that
>> gave the
>> address format
>>
>>
>> Adrian Crum sent the following on 7/26/2008 11:41 AM:
>>> As far as the UI is concerned, what about having an
>> entity that ties a form widget name to a geo code? We could
>> have something like CommonPostalAddressForms.xml that
>> contains the various postal address layouts. Some work
>> might need to be done in the form widget to give it the
>> ability to include "form snippets."
>>> -Adrian
>>>
>>> --- On Sat, 7/26/08, BJ Freeman
>> <bj...@free-man.net> wrote:
>>>> From: BJ Freeman <bj...@free-man.net>
>>>> Subject: Re: Postal Address entity
>>>> To: dev@ofbiz.apache.org
>>>> Date: Saturday, July 26, 2008, 11:31 AM
>>>> ooops
>>>> <field name="postalCodeGeoId"
>>>> type="id"></field>
>>>> which would point to a entity Postalcode with a
>> one to one
>>>> would point to postalCodeLine with a one to one
>>>>
>>>>
>>>> BJ Freeman sent the following on 7/26/2008 11:07
>> AM:
>>>>> the Postal Address in the data book
>>>>> has:
>>>>> address1
>>>>> address1
>>>>> and
>>>>> directions.
>>>>>
>>>>> the postaladdress entity has:
>>>>> toName name
>>>>> attnName name
>>>>>
>>>>> which to me should be using the postaladdress
>> to
>>>> PartyContactMech only
>>>>> these should be removed
>>>>> postalCode short-varchar
>>>>> postalCodeExt short-varchar
>>>>> and just use the
>>>>> <field name="postalCodeGeoId"
>>>> type="id"></field>
>>>>> which would point to a entity Postalcode with
>> a one to
>>>> many (parent to
>>>>> child) would point to postalCodeLine with a
>> one to
>>>> many (parent to child)
>>>>> The reasoning for the refactor is the would
>> like to
>>>> change the
>>>>> PostalAddress to point to a new Entity Address
>> line
>>>>> with a one to many (parent to child) relation
>>>>> it would have a sequence number for getting
>> the proper
>>>> output.
>>>>> this would allow flexibility that is used in
>> other
>>>> countries.
>>>>> the Postal address would also point to new
>> entity
>>>> AddressDirections
>>>>> David E Jones sent the following on 7/26/2008
>> 10:16
>>>> AM:
>>>>>> On Jul 26, 2008, at 10:56 AM, BJ Freeman
>> wrote:
>>>>>>> the databook figure 2.8 has it the way
>> I
>>>> figure it should be.
>>>>>>> is there a reason it was implemented
>> the way
>>>> it was.
>>>>>>> 1) postaladdress has party information
>>>>>> Could you be more specific?
>>>>>>
>>>>>>> 2) it has Postal Code instead of being
>> in the
>>>> geography boundary
>>>>>> It actually has both.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
>
>
Re: Postal Address entity
Posted by Adrian Crum <ad...@yahoo.com>.
I think my suggestion would accomplish both, without the need to change the xsd or have sequence numbers.
-Adrian
--- On Sat, 7/26/08, BJ Freeman <bj...@free-man.net> wrote:
> From: BJ Freeman <bj...@free-man.net>
> Subject: Re: Postal Address entity
> To: dev@ofbiz.apache.org
> Date: Saturday, July 26, 2008, 12:29 PM
> I also proposed a change to the entity.xsd that would put in
> output
> format per field.
> then the output would be drive by using output format
> with what I proposed just in the address, only need to sort
> by the
> sequence number to have correct line numbers
> for input there would have to be an entity in country that
> gave the
> address format
>
>
> Adrian Crum sent the following on 7/26/2008 11:41 AM:
> > As far as the UI is concerned, what about having an
> entity that ties a form widget name to a geo code? We could
> have something like CommonPostalAddressForms.xml that
> contains the various postal address layouts. Some work
> might need to be done in the form widget to give it the
> ability to include "form snippets."
> >
> > -Adrian
> >
> > --- On Sat, 7/26/08, BJ Freeman
> <bj...@free-man.net> wrote:
> >
> >> From: BJ Freeman <bj...@free-man.net>
> >> Subject: Re: Postal Address entity
> >> To: dev@ofbiz.apache.org
> >> Date: Saturday, July 26, 2008, 11:31 AM
> >> ooops
> >> <field name="postalCodeGeoId"
> >> type="id"></field>
> >> which would point to a entity Postalcode with a
> one to one
> >> would point to postalCodeLine with a one to one
> >>
> >>
> >> BJ Freeman sent the following on 7/26/2008 11:07
> AM:
> >>> the Postal Address in the data book
> >>> has:
> >>> address1
> >>> address1
> >>> and
> >>> directions.
> >>>
> >>> the postaladdress entity has:
> >>> toName name
> >>> attnName name
> >>>
> >>> which to me should be using the postaladdress
> to
> >> PartyContactMech only
> >>>
> >>> these should be removed
> >>> postalCode short-varchar
> >>> postalCodeExt short-varchar
> >>> and just use the
> >>> <field name="postalCodeGeoId"
> >> type="id"></field>
> >>> which would point to a entity Postalcode with
> a one to
> >> many (parent to
> >>> child) would point to postalCodeLine with a
> one to
> >> many (parent to child)
> >>> The reasoning for the refactor is the would
> like to
> >> change the
> >>> PostalAddress to point to a new Entity Address
> line
> >>> with a one to many (parent to child) relation
> >>> it would have a sequence number for getting
> the proper
> >> output.
> >>> this would allow flexibility that is used in
> other
> >> countries.
> >>> the Postal address would also point to new
> entity
> >> AddressDirections
> >>>
> >>> David E Jones sent the following on 7/26/2008
> 10:16
> >> AM:
> >>>> On Jul 26, 2008, at 10:56 AM, BJ Freeman
> wrote:
> >>>>
> >>>>> the databook figure 2.8 has it the way
> I
> >> figure it should be.
> >>>>> is there a reason it was implemented
> the way
> >> it was.
> >>>>> 1) postaladdress has party information
> >>>> Could you be more specific?
> >>>>
> >>>>> 2) it has Postal Code instead of being
> in the
> >> geography boundary
> >>>> It actually has both.
> >>>>
> >>>> -David
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >
> >
> >
> >
> >
> >
Re: Postal Address entity
Posted by BJ Freeman <bj...@free-man.net>.
I also proposed a change to the entity.xsd that would put in output
format per field.
then the output would be drive by using output format
with what I proposed just in the address, only need to sort by the
sequence number to have correct line numbers
for input there would have to be an entity in country that gave the
address format
Adrian Crum sent the following on 7/26/2008 11:41 AM:
> As far as the UI is concerned, what about having an entity that ties a form widget name to a geo code? We could have something like CommonPostalAddressForms.xml that contains the various postal address layouts. Some work might need to be done in the form widget to give it the ability to include "form snippets."
>
> -Adrian
>
> --- On Sat, 7/26/08, BJ Freeman <bj...@free-man.net> wrote:
>
>> From: BJ Freeman <bj...@free-man.net>
>> Subject: Re: Postal Address entity
>> To: dev@ofbiz.apache.org
>> Date: Saturday, July 26, 2008, 11:31 AM
>> ooops
>> <field name="postalCodeGeoId"
>> type="id"></field>
>> which would point to a entity Postalcode with a one to one
>> would point to postalCodeLine with a one to one
>>
>>
>> BJ Freeman sent the following on 7/26/2008 11:07 AM:
>>> the Postal Address in the data book
>>> has:
>>> address1
>>> address1
>>> and
>>> directions.
>>>
>>> the postaladdress entity has:
>>> toName name
>>> attnName name
>>>
>>> which to me should be using the postaladdress to
>> PartyContactMech only
>>>
>>> these should be removed
>>> postalCode short-varchar
>>> postalCodeExt short-varchar
>>> and just use the
>>> <field name="postalCodeGeoId"
>> type="id"></field>
>>> which would point to a entity Postalcode with a one to
>> many (parent to
>>> child) would point to postalCodeLine with a one to
>> many (parent to child)
>>> The reasoning for the refactor is the would like to
>> change the
>>> PostalAddress to point to a new Entity Address line
>>> with a one to many (parent to child) relation
>>> it would have a sequence number for getting the proper
>> output.
>>> this would allow flexibility that is used in other
>> countries.
>>> the Postal address would also point to new entity
>> AddressDirections
>>>
>>> David E Jones sent the following on 7/26/2008 10:16
>> AM:
>>>> On Jul 26, 2008, at 10:56 AM, BJ Freeman wrote:
>>>>
>>>>> the databook figure 2.8 has it the way I
>> figure it should be.
>>>>> is there a reason it was implemented the way
>> it was.
>>>>> 1) postaladdress has party information
>>>> Could you be more specific?
>>>>
>>>>> 2) it has Postal Code instead of being in the
>> geography boundary
>>>> It actually has both.
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>
>
>
>
>
>
Re: Postal Address entity
Posted by Adrian Crum <ad...@yahoo.com>.
As far as the UI is concerned, what about having an entity that ties a form widget name to a geo code? We could have something like CommonPostalAddressForms.xml that contains the various postal address layouts. Some work might need to be done in the form widget to give it the ability to include "form snippets."
-Adrian
--- On Sat, 7/26/08, BJ Freeman <bj...@free-man.net> wrote:
> From: BJ Freeman <bj...@free-man.net>
> Subject: Re: Postal Address entity
> To: dev@ofbiz.apache.org
> Date: Saturday, July 26, 2008, 11:31 AM
> ooops
> <field name="postalCodeGeoId"
> type="id"></field>
> which would point to a entity Postalcode with a one to one
> would point to postalCodeLine with a one to one
>
>
> BJ Freeman sent the following on 7/26/2008 11:07 AM:
> > the Postal Address in the data book
> > has:
> > address1
> > address1
> > and
> > directions.
> >
> > the postaladdress entity has:
> > toName name
> > attnName name
> >
> > which to me should be using the postaladdress to
> PartyContactMech only
> >
> >
> > these should be removed
> > postalCode short-varchar
> > postalCodeExt short-varchar
> > and just use the
> > <field name="postalCodeGeoId"
> type="id"></field>
> > which would point to a entity Postalcode with a one to
> many (parent to
> > child) would point to postalCodeLine with a one to
> many (parent to child)
> > The reasoning for the refactor is the would like to
> change the
> > PostalAddress to point to a new Entity Address line
> > with a one to many (parent to child) relation
> > it would have a sequence number for getting the proper
> output.
> > this would allow flexibility that is used in other
> countries.
> > the Postal address would also point to new entity
> AddressDirections
> >
> >
> > David E Jones sent the following on 7/26/2008 10:16
> AM:
> >> On Jul 26, 2008, at 10:56 AM, BJ Freeman wrote:
> >>
> >>> the databook figure 2.8 has it the way I
> figure it should be.
> >>> is there a reason it was implemented the way
> it was.
> >>> 1) postaladdress has party information
> >> Could you be more specific?
> >>
> >>> 2) it has Postal Code instead of being in the
> geography boundary
> >> It actually has both.
> >>
> >> -David
> >>
> >>
> >>
> >>
> >
> >
> >
> >
Re: Postal Address entity
Posted by BJ Freeman <bj...@free-man.net>.
ooops
<field name="postalCodeGeoId" type="id"></field>
which would point to a entity Postalcode with a one to one
would point to postalCodeLine with a one to one
BJ Freeman sent the following on 7/26/2008 11:07 AM:
> the Postal Address in the data book
> has:
> address1
> address1
> and
> directions.
>
> the postaladdress entity has:
> toName name
> attnName name
>
> which to me should be using the postaladdress to PartyContactMech only
>
>
> these should be removed
> postalCode short-varchar
> postalCodeExt short-varchar
> and just use the
> <field name="postalCodeGeoId" type="id"></field>
> which would point to a entity Postalcode with a one to many (parent to
> child) would point to postalCodeLine with a one to many (parent to child)
> The reasoning for the refactor is the would like to change the
> PostalAddress to point to a new Entity Address line
> with a one to many (parent to child) relation
> it would have a sequence number for getting the proper output.
> this would allow flexibility that is used in other countries.
> the Postal address would also point to new entity AddressDirections
>
>
> David E Jones sent the following on 7/26/2008 10:16 AM:
>> On Jul 26, 2008, at 10:56 AM, BJ Freeman wrote:
>>
>>> the databook figure 2.8 has it the way I figure it should be.
>>> is there a reason it was implemented the way it was.
>>> 1) postaladdress has party information
>> Could you be more specific?
>>
>>> 2) it has Postal Code instead of being in the geography boundary
>> It actually has both.
>>
>> -David
>>
>>
>>
>>
>
>
>
>
Re: Postal Address entity
Posted by BJ Freeman <bj...@free-man.net>.
the Postal Address in the data book
has:
address1
address1
and
directions.
the postaladdress entity has:
toName name
attnName name
which to me should be using the postaladdress to PartyContactMech only
these should be removed
postalCode short-varchar
postalCodeExt short-varchar
and just use the
<field name="postalCodeGeoId" type="id"></field>
which would point to a entity Postalcode with a one to many (parent to
child) would point to postalCodeLine with a one to many (parent to child)
The reasoning for the refactor is the would like to change the
PostalAddress to point to a new Entity Address line
with a one to many (parent to child) relation
it would have a sequence number for getting the proper output.
this would allow flexibility that is used in other countries.
the Postal address would also point to new entity AddressDirections
David E Jones sent the following on 7/26/2008 10:16 AM:
>
> On Jul 26, 2008, at 10:56 AM, BJ Freeman wrote:
>
>> the databook figure 2.8 has it the way I figure it should be.
>> is there a reason it was implemented the way it was.
>> 1) postaladdress has party information
>
> Could you be more specific?
>
>> 2) it has Postal Code instead of being in the geography boundary
>
> It actually has both.
>
> -David
>
>
>
>
Re: Postal Address entity
Posted by David E Jones <jo...@hotwaxmedia.com>.
On Jul 26, 2008, at 10:56 AM, BJ Freeman wrote:
> the databook figure 2.8 has it the way I figure it should be.
> is there a reason it was implemented the way it was.
> 1) postaladdress has party information
Could you be more specific?
> 2) it has Postal Code instead of being in the geography boundary
It actually has both.
-David