Post #30,009
2/27/02 1:40:41 PM
|
Re: Your favorite UI field management tools/techniques?
Without data dictionaries allowed, perhaps an OOP solution with sub-classes like:
class zipCode inherits Field {
self.entity = "contact"
self.fldName = "zipcode"
self.fldType = "number"
self.maxLength = 9
self.required = True
self.queriable = True
etc....
}
Or better yet make a generic zip code field. Create a data dictionary that associates that gui widget with the contact.zipcode property. You could even customize the widget to take parameters that are supplied by the data dictionary to make it even more dynamic. Creating a seperate widget for each field would be unfortunate.
Barring data dictionaries, this actually might be a decent use of OOP classes. The busy-work part might be getting it into a sorted collection so that one can iterate thru all the relavent fields without having to instantiate each field class instance in-line. Otherwise you end up with nearly the same problem of having to visit different spots to add new fields or change the ordering. (The perils of non-relational collections.)
Why not create a data dictionary? You can store the mappings in a database or XML file or ini file. Free yourself from your relational ball and chain and experience the options available.
Automating the generation and maintenance of typical data entry/browse/query forms/screens can be a huge time-saver and code debloater. The trick is to make the easy stuff easy without limiting the ability to customize and tweek fields as needed. You know, the ol' 80/20 rule.
See the create a generic zip code field comment above. I can imagine merging XML data from a database query with an XML data dictionary using XSL to do what you're talking about. (Just don't have the time to do anything more than imagine it :( )
(BTW, I still say that businesses want GUI's over HTTP for B-to-B and intrnets and not web junk. All that is missing is a good GUI-over-HTTP standard {like SCGUI}. DOM ain't it. It comes up again and again: they keep wanting to make HTML pages act like GUI's.)
Take a look at [link|http://webfx.eae.net/webboard/|[link|http://webfx.eae.net/webboard/|http://webfx.eae.net/webboard/]]. The connection is a little slow and you'll need IE 5.5 or higher. It's all DHTML. Its rare that you'd need anything else for a business app.
Regards,
John Urberg
|
Post #30,081
2/27/02 8:34:41 PM
|
XML < tables
>> Or better yet make a generic zip code field. <<
If I have my way, there is only *one* Contact table that stores typical address information. Thus, there would be no need to format multiple zipcodes from different entities.
>> Create a data dictionary that associates that gui widget with the contact.zipcode property. You could even customize the widget to take parameters that are supplied by the data dictionary to ....<<
If I could use a DD, then why would I need a "widget" in the first place? (Unless to interface with an existing RAM-centric GUI API. But, I am mostly focusing on Web interfaces anyhow at the moment.)
BTW, a dictionary variable could be used in place of that class example I showed. Thus, I withdrawl my class suggestion.
>> Why not create a data dictionary? You can store the mappings in a database or XML file or ini file. Free yourself from your relational ball and chain and experience the options available. <<
What the fudge are you talking about? XML is like hard-to-read tables without indexes and relational algebra. That is NOT an improvement.
Like I said, I cannot create a DD because the powers that be are not used to them. Ask Norm, he knows all about such situations.
>> The connection is a little slow and you'll need IE 5.5 or higher. <<
I have 5.0 and not in a mood to install a bloated update right now.
So much for "open standard". But, thanks for the link anyhow. One of these days I might try it on a different machine.
________________
oop.ismad.com
|
Post #30,124
2/28/02 3:47:52 AM
|
Re: XML < tables
How would you cope with a contacts table that has to store data from international people? You've got UK postcodes (like "TS14 6NG") versus American ones, ("23423")...
Peter
Shill For Hire
[link|http://www.kuro5hin.org|There is no K5 Cabal]
|
Post #30,178
2/28/02 1:47:18 PM
|
not sure how internationalism relates to topic
>> How would you cope with a contacts table that has to store data from international people? <<
Why is that a concern related to the issues presented?
I am not sure British "post codes" are the same thing as a zip-code anyhow. Perhaps either make a new field for them, or key the post-codes into the general address textbox.
If 98 percent of all contacts in the DB are U.S., then making special fields or formatting/validation for foreign addresses may not be worth the effort. As long as there is sufficient room to type them in when they do come up.
Making a truely international contact manager with full validation is an entire topic in itself. (I suggest you fork off a new discussion if you want to delve into that).
________________
oop.ismad.com
|
Post #30,247
2/28/02 7:12:38 PM
|
YAN perfect illustration of the benefits of polymorphism...
Bryce doesn't understand (surprise, surprise!) what Peter is talking about: >> How would you cope with a contacts table that has to store data from international people? <<
Why is that a concern related to the issues presented? Because the American formatting rules you put there would reject a perfectly legitimate British post code, you numbskull. I am not sure British "post codes" are the same thing as a zip-code anyhow. A "zip code" (let's keep the quotes where they're needed) is EXACTLY the same as what the British (and every other civilised country) calls a 'post code', fuckwit. Only in Amerika it needs, apparently, to have a flash-bang name as if it were a toy for five-year-olds. Perhaps either make a new field for them, or key the post-codes into the general address textbox. Whoopee, what a great idea! And then we add one column for every bloody country in the world that has different-format postal codes, and fuck up our application logic with selecting *different columns* depending on the value of the Country column! Even for *you*, that's AWESOMELY FUCKING BRILLIANT, Bryce! If 98 percent of all contacts in the DB are U.S., then making special fields or formatting/validation for foreign addresses may not be worth the effort. As long as there is sufficient room to type them in when they do come up. A) And if NOT "98 percent of all contacts in the DB are U.S."? 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?!? Fuck, you're being even more stupid than usual, today... Making a truely international contact manager with full validation is an entire topic in itself. (I suggest you fork off a new discussion if you want to delve into that). Let's finish this validation thing *without* any unwarranted assumptions about "98 percent of all contacts in the DB are U.S." first, shall we...? No trying to gallop off into the sunset on fuck-knows-what tangents that come into your, let's be charitable and call it, mind. So how did you just "type them in when they do come up", again? 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? Fix basics like that, before you go whining for repositories and other such stuff -- until you do, those are obviously way over your head. oop.ismad.com Not half as mad as you, mr Hatter. Christian R. Conrad
Of course, who am I to point fingers? I'm in the "Information Technology" business, prima facia evidence that there's bats in the bell tower. -- [link|http://z.iwethey.org/forums/render/content/show?contentid=27764|Andrew Grygus]
|
Post #30,266
2/28/02 10:55:37 PM
|
Trying
Trying to get a discussion moved to the flame forum is not a socially acceptable behavior.
Jay
|
Post #30,286
3/1/02 3:37:17 AM
|
Who's trying?
You think *that* was a "flame"?!?
Sheesh...
Christian R. Conrad
Of course, who am I to point fingers? I'm in the "Information Technology" business, prima facia evidence that there's bats in the bell tower. -- [link|http://z.iwethey.org/forums/render/content/show?contentid=27764|Andrew Grygus]
|
Post #30,271
3/1/02 12:58:15 AM
|
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
|
Post #30,303
3/1/02 9:43:47 AM
|
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.
|
Post #30,348
3/1/02 2:24:30 PM
|
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
|
Post #30,396
3/1/02 5:05:50 PM
3/1/02 5:07:04 PM
|
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]
Edited by Arkadiy
March 1, 2002, 05:07:04 PM EST
|
Post #30,420
3/1/02 9:59:07 PM
|
Yes, the programmer should present tradeoffs to customer
I didn't say otherwise. If I accidently implied it, I apologize.
________________
oop.ismad.com
|
Post #30,177
2/28/02 1:32:27 PM
|
Re: XML < tables
Well, if you absolutely can't even store them in a file, create the DD in memory. For example:
class DataDictionaryEntry {
final static int NUMBER_TYPE = 1;
final static int TEXT_TYPE = 2;
private String name;
private String title;
private int type;
private int width;
<etc>
public DataDictionaryEntry(String name, String title, <etc) {
super();
this.name = name;
<etc>
}
public void configure(Widget aWidget) {
aWidget.setTitle(title);
aWidget.setWidth(width);
<etc>
}
<etc>
}
public interface Widget {
public void setTitle(String title);
public void setWidth(int width);
<etc>
}
and then load em up:
HashTable dd = new HashTable();
dd.put("zip_code", new DataDictionaryEntry("zip_code", "Zip Code:", <etc>));
dd.put("first_name", new DataDictionaryEntry("first_name", "First Name:", <etc>));
make your fields configurable:
public class ConfigurableTextField extends TextField implements Widget {
public setTitle(String aTitle) {
this.setLabel(aTitle);
}
<etc>
}
and then configure your fields:
((Widget)dd.at("zip_code")).configure(this.zipCodeField);
((Widget)dd.at("first_name")).configure(this.firstNameField);
<etc>
Instant data dictionary. You can do a few more rounds of design yourself and make it even better. Maybe create a data dictionary class that has a method to take a field name and widget and does the lookup itself for example. I just thought this up in a few minutes as I typed it. Regards,
John Urberg
|
