IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New There are a whole range of options. Why fuss about 1sugstn?
>> Because the American formatting rules you put there would reject a perfectly legitimate British post code, you numbskull. <<

Like an IF statement can't fix such?

If rs.country = Brits
....do this
else
....do this
end if


Of course a full-blown int'l system would have to be more systematic. Tables of potential fields and another "link" table of country's to match them to (and a 3rd Country table, of course). A 4th data table may resemble the link table, but with a Value field.

In practice, this is probably overkill except in high-end contact mgmt apps. Looking at the actual pattern, one would probably see there are ways to simplify it.


>> Whoopee, what a great idea! And then we add one column for every bloody country in the world that has different-format postal codes <<


It was only one suggestion among others. Whether we have different fields OR different validation rules for the *same* field is one of those design decisions that would have to be looked into by studying address patterns. If the fields were dynamically generated from a DD-like gizmo, then does not really matter.


>> B) So what's that "validation" _do_, then... If you can just "type them in when they do come up", with no regard to it?!? <<

I don't understand. In the simplest case you just:

If rs.Country = US
. . . validate
end if

IOW, turn off validation if non-US (under the 98% assumption).

Note that not all contacts may have complete info anyhow. IOW, you wouldn't want to force zipcode entry if the keyer does not have zipcode info available. Maybe just a warning. Going with this aproach, we may not need the above IF statement. A British zipcode would simply give a warning, which can be bypassed if not appropriate.

>> And can we have some example code to see how you handle writing adress labels from a database table with ~150 coulmns to choose the postal code from? <<

See above.

If you provide a more specific scenario, I would be glad to exchange psuedo-code with you. You would need to supply things like the country percentages expected, validation intensity needs, etc.

________________
oop.ismad.com
New I don't know how to do it, so let's not do it.
That's the second time you have this attitude. Please note that you are turning off validation when it is most useful: on rarely used format which, when mistyped, will cause maximum delay/pain.
New If one-size-fits-all, then please show your genius
>> That's the second time you have this attitude. Please note that you are turning off validation when it is most useful: on rarely used format which, when mistyped, will cause maximum delay/pain. <<

A small company is generally *not* going to implement a system that checks every country's address for formatting errors.

Do you agree with this?

A large multinational company may indeed want such a system.

And there are millions of in-betweeners who have various ranges of non-US contacts and accuracy needs.

(There might be commercial components for this. I have not checked.)

It is continious. If you have a simple, generic solution for all-size biz's, then lets see it.

Otherwise, stick an object in your pie holes.
________________
oop.ismad.com
New It's not about a small company,
it's about you. If _you_ are given a task to implement it, you can't just say: "Ah, it's only 5% of our database, we don't have to care." If you say so, you are bullshitting your customer/boss.

Any competent programmer should shudder at a solution like you suggested. Yes, you could leave 5% of the user input unvalidated if you absolutely don't have resources to implement validation. But _you_, the programmer, should explain the risks to your management and fight for a complete solution. You may lose, for a business reason. But you must not fight for the wrong side.

[edited spelling]
Expand Edited by Arkadiy March 1, 2002, 05:07:04 PM EST
New Yes, the programmer should present tradeoffs to customer
I didn't say otherwise. If I accidently implied it, I apologize.
________________
oop.ismad.com
     Your favorite UI field management tools/techniques? - (tablizer) - (15)
         Re: Your favorite UI field management tools/techniques? - (johnu) - (12)
             XML < tables - (tablizer) - (11)
                 Re: XML < tables - (pwhysall) - (9)
                     not sure how internationalism relates to topic - (tablizer) - (8)
                         YAN perfect illustration of the benefits of polymorphism... - (CRConrad) - (7)
                             Trying - (JayMehaffey) - (1)
                                 Who's trying? - (CRConrad)
                             There are a whole range of options. Why fuss about 1sugstn? - (tablizer) - (4)
                                 I don't know how to do it, so let's not do it. - (Arkadiy) - (3)
                                     If one-size-fits-all, then please show your genius - (tablizer) - (2)
                                         It's not about a small company, - (Arkadiy) - (1)
                                             Yes, the programmer should present tradeoffs to customer - (tablizer)
                 Re: XML < tables - (johnu)
         Re: Your favorite UI field management tools/techniques? - (JayMehaffey) - (1)
             Perhaps it is similar to.... - (tablizer)

Ash nazg durbatuluk, ash nazg gimbatul. Ash nazg thrakatuluk agh burzum-ishi krimpatul.
44 ms