best practices for international addresses?

[prophoto]

I found the earlier post using a db join and importing a list of countries, worked great. This will help to prevent typos and make for cleaner site searches and setup. http://fabrikar.com/forums/index.ph...lement-with-list-of-countries-in-world.31685/

I need to setup international addresses on my lis site. Ideally I would list all cities in an autocomplete, allowing the user to choose the correct one (like countries above with a dbjoin) preventing any typos. I see there are also a number of free city lists, should I bother to import one of those lists or just setup cities as an auto-complete allowing user entries?

 

[focault]

I would say force them with a joined list - users are stupid

 

[prophoto]

cheesegrits thoughts? Also worried about performance as this form already has about 30-40 fields and 3 other joins.

 

[cheesegrits]

Kind of depends if the lists you've found are complete or not. I always recommend using tables for things like cities, states, countries, etc. As focault says, users are stupid. Give them an opportunity to mis-spell things, and they will. But the problem with tables is, they have to be complete, and kept up to date. And a table of "all the cities in the world" would be tough to keep maintained.

Also, I'm not sure what you mean by ...

should I bother to import one of those lists or just setup cities as an auto-complete allowing user entries?

Do you mean a join element set to auto-complete? I'm confused by the "or" there. To use an auto-complete, you'd still need it to be a join element, so you'd need to import a cities table in to your database.

Unless you mean a field element set to "values" ... in which case, that can lead to self perpetuating errors, as it'll show matching mis-spellings. So once "Philadlephia" is in there for "Philadelphia", folk will select it.

I wouldn't foresee any performance issue, as long as you DON'T do it as a dropdown with tens of thousands of entries on it. I was just working on someone else's form with 150+ elements and about a dozen joins to large tables, no performance problems.

-- hugh