> 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/