|
|
Posted by shimmyshack on 04/19/07 01:51
On Apr 19, 2:13 am, sgotte...@yahoo.com wrote:
> Hello,
> If you could assist me with the following situation, I would be very
> grateful.
>
> I have a table of data retrieved from database displayed on screen.
> To each row of data, I have added action buttons, such as "Edit",
> "Add", and "Comment". Since I do not know how many rows of data will
> be retrieved - and therefore how many buttons I need - I am using
> button arrays for each button, like so:
> echo "<input type=\"submit\" value=\"Comment\" name=\"Comment[]\" />";
>
> In the php file that processes the input from this form, I have the
> following code, which I was under the impression would give me the
> index in the Comment array of the button that was fired.
> if (isset($_POST['CommentMedicalHistory']))
> {
> $indexOfComment = each($_POST['CommentMedicalHistory']);
> echo "index = {$indexOfComment['key']}";}
>
> Unfortunately, it is returning 0 as the index all the time, even when
> I do not click on the Comment button in the first row.
> Do you know by any chance how I could get the correct index of the
> button that was pressed from the array?
>
> Thank you, once again, for any assistance that you can provide,
> Simon Gottesman
although this approach could work, it might not work as you intend if
the database has changed since the rows were received. your comment
could be associated with the wrong row in the db.
Perhaps what you need is an ID for each row, so that you can associate
the button with that id, create a column and populate it with a unique
ID, you /could/ use an auto_increment column, but will probably find
it easier in the long run if you don't and simply adjust your table
and populate it manually when updating and altering the table.
the job of creating unique names for your inputs is now easy.
watch how much data you retunr though, creating buttons for each
(possibly unused) row means more in the DOM (more in memory) and more
clutter on the page.
Consider using javascript to add to the DOM only what the user wishes
to edit, adding a small form with the 3 or so buttons, which appear
below the row when the user clicks, if you add an iframe too pointing
towards the update script, you have an AJAX style synamic updater
which can be used repeatedly on the same page to update many rows with
no need for a refresh with its database querying overhead. Once again
thoughm if the rows can be edited by more than one user at a time,
make sure the logic checks for changes before overwriting. To do this
you could populate a session serverside with the results from the
database, and check that the values from the session are still the
same as the values from the database, before updating. I know its a
hassle, but will avoid too many users upsetting each other, the good
news is that when a user changes the database while another user is
attempting to do it, you can notify the other user without them
leaving the page, of the new value, and ask whether they wish to still
carry on. Just ignore all this if its never likely to grow to the
point where you care about this. Its just that since you are returning
a lot of data (by the sound of it) it suggested to me that the data
counld be presented to multiple users at once if multple users are
using that part of the app. and although the chances of each user
updating the same row could be seen to be small compared to the set
size, the context is what will drive the need to update, rather than
the simple probability, and so it could be a problem. rabbit rabbit,
perhaps i need sleep!
Navigation:
[Reply to this message]
|