|
|
Posted by sgottenyc on 04/19/07 15:15
On Apr 19, 9:57 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> shimmyshack wrote:
> > On Apr 19, 5:28 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> >> 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
> >> Simon,
>
> >> Since you can only press one button to submit your form, you will only
> >> get one button back - and it's index will always be zero. In the case
> >> of a submit button, the brackets in 'name="Comment[]"' are superfluous -
> >> you can't get back more than one button.
>
> >> What you want is to get the id of the row (you do have a unique ID for
> >> each row, right?) and use it in your name, i.e.
>
> >> " ... name=\"comment[$id]\" ... "
>
> >> Now you can get the $_POST['comment'] array and check your key to get
> >> the id of the row.
>
> >> No javascript or DOM needed.
>
> >> Of course, there are other ways, but I like this one.
>
> >> --
> >> ==================
> >> Remove the "x" from my email address
> >> Jerry Stuckle
> >> JDS Computer Training Corp.
> >> jstuck...@attglobal.net
> >> ==================
>
> > i suppose it could be added that the [] technique /can/ be very useful
> > if you are making many comments at once, which is what I assumed.
> > another eg. When you are /submitting/ a lot of inputs each with unique
> > values which taken together mean something, for instance a series of
> > ordered triples, like 3D coordinates.
> > As Jerry points out, you don't need js if you print out the full DOM
> > in markup, you are advised to use paging with a LIMIT BY clause in
> > your sql, to ensure things don't grow unmanageably as the data in the
> > table grows.
>
> He doesn't need the full DOM at all. Just use the row id as the index
> to the array.
>
> There needs to be some unique way to identify the row in the database.
> Otherwise you can get the wrong row, i.e. if the database has changed as
> you noted.
>
> Whether it's an autoincrement or other type of column, that identifier
> can be used as the index to the array. Then it's easy to retrieve the
> correct row all the time.
>
> And I agree - he needs to limit the amount of data returned now, not later.
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstuck...@attglobal.net
> ==================- Hide quoted text -
>
> - Show quoted text -
Thank you both for your replies.
I will try Jerry's approach first, as I was already leaning towards
trying something like that (and I already have an index keeping track
of the number of rows both on the page and in the database). I think
I might be lucky in this case and not have to deal with the issue
shimmyshack raised, of buttons becoming dissociated from the correct
rows in the database, since, in this application, rows cannot be
deleted - only added or edited. Also, I think that I won't have to
deal with more than 20 to 40 rows of data at a time- so the issue of
too much data might also be avoided. Though if it becomes an issue, I
might be able to limit it further.
Navigation:
[Reply to this message]
|