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:

Previous
From: Paul Comitz
Date:
Subject: gmake fails with 7.2.2
Next
From:
Date:
Subject: Re: Form Design Advice