Question on best practice for allowing edits of lists

[Mark Feller]

I want to provide users a page where they can browse entries in a database
10 at a time, for example. I am doing this as a table, where each row is a
database entry. I want to be able to give the user the ability to modify
entries. By either clicking on a link or a button on each row, I want the
user to be sent to another page to edit that entry.

What is the best way to track which entry the user is wanting to edit?

Thanks for ideas...

[rik]

Re: Question on best practice for allowing edits of lists

Make each entry in the table a hyperlink with the querystring
containing a primary key reference.

<a href='edit_entr y.php?id=1'>Edi t This Entry</a>

On the edit_entry.php page read the primary key in and use it to find
the item you are wanting them to edit.

Using a form is also easy and just involves having a hidden variable
storing the primary key id in it.

In terms of which is best, I'd only use a form when I need lots of info
to be passed (such as on the edit_entry.php page where you will hae a
number of fields to update). Having a big grey button at the end of
each row will also detract from the text contained in the row so would
be less visually pleasing (especially 10 or so unerneath one another).

Either way is fine though, just a preference of mine.

Rick

[rik]

Re: Question on best practice for allowing edits of lists

Make each entry in the table a hyperlink with the querystring
containing a primary key reference.

<a href='edit_entr y.php?id=1'>Edi t This Entry</a>

On the edit_entry.php page read the primary key in and use it to find
the item you are wanting them to edit.

Using a form is also easy and just involves having a hidden variable
storing the primary key id in it.

In terms of which is best, I'd only use a form when I need lots of info
to be passed (such as on the edit_entry.php page where you will hae a
number of fields to update). Having a big grey button at the end of
each row will also detract from the text contained in the row so would
be less visually pleasing (especially 10 or so unerneath one another).

Either way is fine though, just a preference of mine.

Rick

https://www.e-connected.com

[bingomanatee]

Re: Question on best practice for allowing edits of lists

One concern with the process of editing records is simultaneous
editing.

That is user A clicks on the link and begins editing..

Then user B, a quicker sort of person, does the same thing and SAVES
FIRST.

User A is still on the form page, plodding along and finally finishes
and hits the SAVE button, overwriting B's changes.

The classic rule is that you shouldn't be able to save over a record
that has been edited underfoot.

The easiest way to check this is to use a timestamp field (I'm using
mySQL vernacular) -- that is, a field whose date is set every time the
record is saved. (You can use a conventional date field and manually
set it to now() using SQL every time you save. I tend to call this
field "updated" by convention.

Load the old 'updated' field into a hidden field on the form.

The form will submit to a save_record.php page (or some such) and on
this page, BEFORE YOU SAVE, do a SELECT to determne the records'
current value for 'updated'. if it is different from the 'updated'
value that the record had when you loaded it, don't resave the data.
give the user an error message ("Your record has been edited by someone
else; your changes haven't been made. ) and return them to the list
view. If they want, they can click on the record and edit it again.

Also, in the event that someone else has deleted the record, you might
want to check that there is a record in the system with the current ID.


Ideally you'd have a "check out" system that prevented user B from
opening the record when user A was editing it, but in the web
environment it's very problematic to do this because its tough to
determine when the user has shifted gears (left the edit page without
saving the record) so "stale checkouts" are common.

These security measures are most necessary in data held in common by
several users. Private records like BLOG pages or user_ID records
probably don't need asynchronous edit protection.

[SOR]

Re: Question on best practice for allowing edits of lists

<comp.lang.ph p , Mark Feller , mjf77@lycos.com>
<356Ge.500$gQ5. 419@newssvr33.n ews.prodigy.com >
<Thu, 28 Jul 2005 14:37:51 GMT>
[color=blue]
> I want to provide users a page where they can browse entries in a database
> 10 at a time, for example. I am doing this as a table, where each row is a
> database entry. I want to be able to give the user the ability to modify
> entries.
>[/color]

What if 2-3 users are editing the same 10 entrys at the same time .

- one user saves a entry
- another user saves the same entry 30 seconds later

[Steve]

Re: Question on best practice for allowing edits of lists

On Thu, 28 Jul 2005 11:38:26 -0700, bingomanatee wrote:
[color=blue]
> One concern with the process of editing records is simultaneous editing.
>
> That is user A clicks on the link and begins editing..
>
> Then user B, a quicker sort of person, does the same thing and SAVES
> FIRST.
>
> User A is still on the form page, plodding along and finally finishes and
> hits the SAVE button, overwriting B's changes.
>
> The classic rule is that you shouldn't be able to save over a record that
> has been edited underfoot.
>
> The easiest way to check this is to use a timestamp field (I'm using mySQL
> vernacular) -- that is, a field whose date is set every time the record is
> saved. (You can use a conventional date field and manually set it to now()
> using SQL every time you save. I tend to call this field "updated" by
> convention.
>
> Load the old 'updated' field into a hidden field on the form.
>
> The form will submit to a save_record.php page (or some such) and on this
> page, BEFORE YOU SAVE, do a SELECT to determne the records' current value
> for 'updated'. if it is different from the 'updated' value that the record
> had when you loaded it, don't resave the data. give the user an error
> message ("Your record has been edited by someone else; your changes
> haven't been made. ) and return them to the list view. If they want, they
> can click on the record and edit it again.
>
> Also, in the event that someone else has deleted the record, you might
> want to check that there is a record in the system with the current ID.
>
>
> Ideally you'd have a "check out" system that prevented user B from opening
> the record when user A was editing it, but in the web environment it's
> very problematic to do this because its tough to determine when the user
> has shifted gears (left the edit page without saving the record) so "stale
> checkouts" are common.
>
> These security measures are most necessary in data held in common by
> several users. Private records like BLOG pages or user_ID records probably
> don't need asynchronous edit protection.[/color]

Why suggest a method that you admit doesn't work? You *don't* need a
timestamp at all ( although it's always handy ). What you need is the
values for all editable fields at the time the update window was opened.

So, stuff a copy of each of these fields into a hidden field or session
var, and then, at update time, check to see that all of those values are
still the same as those stored in the database for the entry in question.

If they've changed, then you can use logic to see whether any of the
current changes are logical, and see how clever you can be in resolving
the problem. Personally, I'd be braindead stupid and refuse, although you
could probably get away with silently ignoring the update if the changes
to be made have all been done by someone else.

The overhead of checking many fields rather than one will never be that
big. As the changes are being made manually, and people don't type that
fast - you'll only ever have a slack handful of changes to make to a
single record.

No stale anything - guaranteed success ( assuming that the select / update
method is atomic, which it isn't ).

My $0.02,

Steve