A week or so ago, David Neumann wrote, in response to Bob Stuart:

> This is a matter of taste and trade-offs. I don't care if the DG isn't
> in synch. Next time my users access the app the page they get back will
> be in synch. Should they ever try to make a state change to the
> database, EOF makes sure everything's in synch and that nothing changed
> under me. I am ensured that I can synch up just-in-time.

I'm not sure I understand what this means...  Let's say I have a DG
that's displaying an array of items.  And I have a link (or button)
on this page that does two things: (1) adds a new item via the DG's
insert method, and (2) takes the user to a page to edit the new EO's
attributes.  On this second page, he can Save or Cancel the addition
of the new item.

So, the user clicks to add a new item, which takes him to the editing
page, then decides (for whatever reason) to backtrack to the page
where the DG is displaying the list of items.  Now, the newly added
item doesn't appear here.  But it *is* being managed by the DG, and is
living at some position in its array.  Let's say the user now clicks
one of the other items in the displayed list to indicate that he wants
to edit its attributes.

He ends up at the edit page, but who knows which item he's going to be
editing.  If the newly added item (above) is *before* the just-clicked
item (i.e. its index in the DG's array is smaller than the index of the
item he clicked to edit), then he's going to end up editing the wrong
item.  Even worse, if he clicks a button to DELETE some item in the
list, he could end up *deleting* the wrong item!

This kind of thing seems fairly serious to me.

> Keep in mind that should the user backtrack to a page and click on a
> link, the page that is returned will be refreshed (just-in-time) which
> is usually benign.  Also, if the user clicks on something in the page
> that should no longer be visible, WO will ONLY refresh the page; nothing
> else will happen.

If I delete an element from a DG (which is being displayed via a
WORepetition), and the page is regen'd (so that the deleted elt is
now gone), and then I backtrack to the page where the deleted element
is still visible, and then click on some OTHER item, chances are, I'm
going to get the wrong item (that is, if the array index of the item
I deleted comes before the index of the elt I later click on).

I suppose this could be more-or-less benign.  But I can also imagine
a user getting an edit page for an unexpected item, backtracking
(thinking he must have clicked on the wrong item), clicking it again,
getting the same unexpected item again, calling me on the phone...

-- 
Patrick Robinson
Extension Information Systems, Virginia Tech
[EMAIL PROTECTED]

Reply via email to