note 16848 added to function.extract

From: Date: Thu, 15 Nov 2001 19:05:50 +0000
Subject: note 16848 added to function.extract
Groups: php.notes 
Request: Send a blank email to php-notes+get-20883@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.) -- http://www.php.net/manual/en/function.extract.php http://master.php.net/manage/user-notes.php?action=edit+16848 http://master.php.net/manage/user-notes.php?action=delete+16848 http://master.php.net/manage/user-notes.php?action=reject+16848

« previous php.notes (#20883) next »