Postal Address entity
Locked
 
|
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 |
|
|
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 |
|
|
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 > > > > |
|
|
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 >> >> >> >> > > > > |
|
|
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 <[hidden email]> wrote: > From: BJ Freeman <[hidden email]> > Subject: Re: Postal Address entity > To: [hidden email] > 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 > >> > >> > >> > >> > > > > > > > > |
|
|
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 <[hidden email]> wrote: > >> From: BJ Freeman <[hidden email]> >> Subject: Re: Postal Address entity >> To: [hidden email] >> 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 >>>> >>>> >>>> >>>> >>> >>> >>> > > > > > > |
|
|
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 <[hidden email]> wrote: > From: BJ Freeman <[hidden email]> > Subject: Re: Postal Address entity > To: [hidden email] > 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 > <[hidden email]> wrote: > > > >> From: BJ Freeman <[hidden email]> > >> Subject: Re: Postal Address entity > >> To: [hidden email] > >> 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 > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > > > > > > > > > > > > |
|
|
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 <[hidden email]> wrote: > >> From: BJ Freeman <[hidden email]> >> Subject: Re: Postal Address entity >> To: [hidden email] >> 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 >> <[hidden email]> wrote: >>>> From: BJ Freeman <[hidden email]> >>>> Subject: Re: Postal Address entity >>>> To: [hidden email] >>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>> >>> >>> >>> >>> > > > > > > |
|
|
In reply to this post by BJ Freeman
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 >> >> >> >> > |
|
|
In reply to this post by BJ Freeman
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 <[hidden email]> wrote: >> >>> From: BJ Freeman <[hidden email]> >>> Subject: Re: Postal Address entity >>> To: [hidden email] >>> 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 >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >> >> >> >> >> >> > |
|
|
In reply to this post by David E Jones
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 >>> >>> >>> >>> >> > > > > |
|
|
In reply to this post by David E Jones
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 <[hidden email]> wrote: >>> >>>> From: BJ Freeman <[hidden email]> >>>> Subject: Re: Postal Address entity >>>> To: [hidden email] >>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> >>> >>> >> > > > > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |