Re: Form Design Advice - Mailing list pgsql-novice
From | |
---|---|
Subject | Re: Form Design Advice |
Date | |
Msg-id | 20050304235210.25279.qmail@web52404.mail.yahoo.com Whole thread Raw |
In response to | Form Design Advice (<operationsengineer1@yahoo.com>) |
List | pgsql-novice |
> There's two kinds of overhead here. Processing > overhead effects your > users. Coding overhead effects you. The following > approach increases the > former to eliminate the latter. If performance is > your main concern, > forget doing anything interesting. However, in my > experience, users will > take a performance hit in stride if what they get at > the end is valuable. i want to display the data for a quick review of data entered so the user can be confident they didn't mis-spell a customer name - "IBM" as "IMB," for example. i think this is necessary, but i'm not sure it has to be done right away (i need current functionality darn it! ;-) and there are several ways of doing this that i need to consider. > In your example, I would ask, how valuable to the > user is the data you > want to display? Will it make her more productive or > efficient? Will it > decrease her mental overhead, making her work > easier, less stressful and > more enjoyable? If so, a few extra seconds is a > small price to pay. good point. it isn't like this app is data entry intensive, either. nobody will be sitting at a desk entering data 8 hours a day. but they might on my next app! ;-) > If you're worried about whether your hardware can > handle the extra load, I > say get new hardware. i'm not. > If your form fields are named after your table > fields, you have a closed > loop from which you can dynamically generate the > bulk of your code. oooooh, aaaaaah. niiiice... i think mine are the same, i just wish i could say i planned to do it that way b/c i had some cool function in mind that required it. -lol- > > First, call the database and build an array of field > names/numbers/types. > http://us4.php.net/manual/en/function.pg-field-name.php > http://us4.php.net/manual/en/function.pg-field-num.php > http://us4.php.net/manual/en/function.pg-field-type.php > i'll do some reading. i'm using adodb so i'll have to check and see if this method is compatible w/o resorting to using the pg api. you have given me (and others) an excellent lead here. thank you much. > Iterate through this array to declare global form > variables. I use > eval(), but I'm pretty sure there's a better way. > > // EXAMPLE ELEMENT ARRAYS: > $arr[$fieldnum][0] = $fieldname; > $arr[$fieldnum][1] = $fieldtype; > > foreach($arr as $a) { > eval("\$" . $a[0] . " = \$_POST[" . $a[0] . "];"; > } is eval the best way to do this? i recall reading somewhere, for som eother project, that eval should rarely be used. not sure if that is a guru's opinion or a quack's quack. > Code your form manually with the proper element > names. Add a hidden > element for each visible element to pass the field's > type for validation > purposes. i'm using manuel lemos' forms class, but i don't think that will cause a problem doing this. > Use the same array to build your insert statement > when the form is submitted, corrected and validated. > > $insert = "insert into table set ("; > $x = 0; > foreach($arr as $a) { > $insert .= $a[0]; > if($x != count($arr - 1)) $insert .= ", "; > $x++; > } > $insert .= ") VALUES ("; > $x = 0; > foreach($arr as $a) { > $insert .= "'" . $$fieldname . "'"; > if($x != count($arr - 1)) $insert .= ", "; > $x++; > } > $insert .= ");"; thanks for the idea and the example. it is much appreciated... and it seems others have gained something valuable, too. :-) __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/
pgsql-novice by date: