note 16848 deleted from function.extract by jimw
| From: | jimw@php.net | Date: | Sat, 08 Dec 2001 19:58:49 +0000 |
| Subject: | note 16848 deleted from function.extract by jimw | ||
| References: | 1 | Groups: | php.notes |
| Request: | Send a blank email to php-notes+get-22159@lists.php.net to get a copy of this message | ||
With reference to extracting the results of
mysql queries i.e.
$my_row = mysql_fetch_assoc($my_cur);
extract($my_row);
and then using $my_field instead of $my_row[my_field];
I would agree that this is no panacea. It's all
too easy to overwrite a value of $my_field from
a related query and if you specify a prefix
e.g. extract($my_row, EXTR_PREFIX_SAME, "my_row");, then there seems little point. Is
$my_row_my_field really better than $my_row[my_field] ?
If you are using forms which offer combined multi-field searches and multi-row updates, it
doesn't really help at all since you probably want to reserve
the plain variable $my_field for the search value.
However, for single-row update forms with limited search where you
either want to redisplay the updated data from
the database or, alternatively, an error message and the data actually input it is useful:
Sample pseudo-logic:
if update-requested
if data valid
update data
else
set error message
endif
endif
if no error message
select data by key
extract row
endif
<HTML>
<FORM>
--error message--
<INPUT TYPE=HIDDEN NAME=my_key
VALUE= $my_key>
<INPUT NAME="my_field" VALUE= $my_field>
<INPUT TYPE=SUBMIT NAME=update>
</FORM>
</HTML>
This saves you explictly copying data values
over input values after a succesful update/search
and automatically copes with new fields.
(In case you wonder why you might want to re-
select data which you have just explicitly updated, the answer is that it helps in debugging. Users
will very quickly spot fields that didn't
get updated for whatever reason.)