On 11/09/11 06:29 -0500, Sharoon Thomas wrote:
> 
> 
> On Sep 11, 2011, at 6:16 AM, Udo Spallek wrote:
> 
> > Hi,
> > Cédric Krier <[email protected]>, Sat, 10 Sep 2011 11:36:12 +0200:
> >> On 09/09/11 20:58 -0700, Bruno (Thymbra) wrote:
> >>> Be a matter of doing some testing with your proposal and check if
> >>> it matches the problem in my country.
> >> I only do a design proposal, I really don't know if I will have time
> >> to work on the implementation but anybody can implement it.
> > We could extend the party module with the functionality to save
> > given tuples of zip(postal code), city, subdivision and country. This
> > will help the users anyway, because they always need to encode these
> > information only once. 
> > 
> > But what exactly should be the functionality? 
> > 
> > * Is it for looking up city and nation names by postal codes? 
> > * Is it for reverse looking up postal codes by cities?
> > 
> >  * Looking up postal codes depends at least in Germany from city, 
> >    street name and house number (See e.g. the table in [4],
> >    'PLZ' is the postal code). Openstreetmap address this
> >    problem by collecting pairs of geo-location and postal code. So
> >    things can get complicated for reverse lookup.
> > 
> > * Or is it both?
> 
> I don't think this can be consistent amongst all service/post codes. For 
> example [1] Brazil offers resolution of post code to the street while Indian 
> post code resolution ends with a  Post Office region (Kind of ID for a post 
> office).
> 
> So I am really not sure how this could work in a multi country scenario. 
> Perhaps chose the web service based on country (sent in values dictionary by 
> autocomplete).

I think you did not understand the goal of this design. We don't care to be
consistent.
Auto-completion is not a automatic filling values, it is just suggestions to
ease the encoding. The user is still free to encode any values. So we don't
care if a post code is linked to one or many cities or if a cities has many or
just one post code, we just suggeste what we know.
It is possible to do it with the current database design but it will not allow
to prefill Tryton with know data.

About prefilling, as I said to be part of Tryton it will require to be
reliable. If there is no such providers, we just don't include it.

About web service, I don't like the idea to depend on such webservice. What
happens when it is down? Or the internet connection is down? Or the API has
changed? (There is already such issue with the VIES check)So I don't think
such module can be part of the base but of course it will be easy to implement
it if we already got the on_change/on_complete methods.

-- 
Cédric Krier

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: [email protected]
Website: http://www.b2ck.com/

Attachment: pgpax6ALQ2Y43.pgp
Description: PGP signature

Reply via email to