Forum OpenACS Development: Re: Comments on the new postal-address module (and kin)

Jon, i forgot about site wide search - yea, i agree they should be objects... I agree that address verification via tcl is important - do you also intend to make an address "widget" that can be inserted as an element in forms? i think this would be a great thing - i.e. similar to the way date has a number of fields as an element i think address should also have a numbmer of them - possibly selected via a parameter via acs-templating that lets you select the default countries setup of that input field.

But Jon, as a repository of data, postal-address should not rely on persons - it should rely on itself. I really don't like the constraint on persons and in fact it would make it impossible for me to use it with my contacts app without creating bogus "persons" in all i'm suggesting is changing this part of the postal-adderss table creation script

    party_id            integer
                        constraint postal_owner_id_fk
                            references parties (party_id),

I would like it to become

    object_id           integer
                        constraint postal_owner_id_fk
                            references acs_objects (object_id) 
                        constraint postal_owner_id_nn not null,

since this field can be null in its current state - which i hadn't realize it was - i can use it. in fact i am going to use it and implement it today so i don't start doing things that aren't standardize. However, if that field is not entered then there could be no way of "tracking down" addresses "belong" i.e. you could track the address object 1234 by the use of a map table with contact object 4321. But if lots of apps end up depending on postal-address (which they hopefully will), then i think it would be good to be able to search the postal-address table for all addresses belonging to the objects that particular application owns...

Alfred - john's point that ref-addresses isn't a good idea is a very valid one - that's not the way it would work with openacs standards. we could have a ref-addresses package that stores all this "tiger" data you are talking about but it wouldn't make sense to put unique addresses in there. Do you know of any gnu or gpled reference data that would let us calculate longitude and latitude? As Alfred suggested, I am planning on tcl procs to do address verification. This is not trivial though and the system now works the way it is. Also, none of this has any effect on the data model or HR-XML. Everything you guys are talking about should be built on top of the telecom-number and postal-address services. They are only repositories of data, what you do with them is another package. Marketing data has to be stored seperatly, that is another package. Longitude/Latitude is already incorporated into the ref-zipcodes service. Please note that getting this data is country specific with many if not most countries not having it. It really has no place embedded in the core data model. There will be some changes to persons: alter table persons add column formatted_name varchar(200); alter table persons add column preferred_given_name varchar(100); alter table persons add column middle_name varchar(100); -- need to drop the not null constraint, I believe PG 7.3 allows this. Also, person__new et al need to be replaced. I already did this for PG and Oracle will be just as simple.