Hmm.. I agree with you.

The reason I'm not using wicket versioning is that it would (IMHO) confuse inexperienced users. Because while it is possible to track model changes, it's not possible (or at least easy) to track each database change and make it undoable. So while user can undo some tasks (that only involve model changes), he can't undo other (like delete assignment, in this case). I don't say it's not possible to track database changes, I just don't think it's worth the huge amount of work.

I think that what user sees should be as fresh as possible.

In my application, the back button behaves more like escape button in desktop application. (But not always of course)

In regular desktop application, there's no undo functionality for most of the tasks. Why should it be in web application? I know users are used to back button when browsing. But for navigation, not for undo.

Consider my application. When you view an assignment, then edit consultants, you can do whatever with them (add, remove, change selected company) and suddenly you have changed your mind and want to go back. You can either push the cancel button, or use back button. You only have to press back button once, to get to the assingment. If I used versioning, you would have to press it as many times, as many versions of the page exist.

(I think wicket developers won't agree here. I don't claim that I'm right. It's just my opinion. The good thing about wicket is the choice. I can decide whether to use versioning or not).

About copy and save after. Yes, it really works. It's not a big deal to implement saving even without copy. But I've rather chosen to show the message, I think this is how regular (desktop) application would behave.

> Check this one of mine:
> http://superinterface.com/strutsdialog/cruditemlist.do It actually has
> a flaw: I forgot to mark pages as non-cachable. But whatever. Click
...
Yes, works nice. But I'd prefer to show expired page as soon as you show the expired item. Not just after trying to save it. I guess marking pages as non-cacheable would sove this.

-Matej

Michael Jouravlev wrote:
On 8/3/05, Matej Knopp <[EMAIL PROTECTED]> wrote:

Btw. What do you think would be correct action?

Showing user a message, that assignment has been deleted,

or

Being able to save the assignment, without throwing any exception?

(or showing user a message, that assignment has been deleted and
afterwares go to the assingment and allow to save it)


I personally feel very stronly that the first option (show message) is
the right one, while I know that Eelco and Jonathan would disagree.

I can explain my point of view again. What you (or user) see in a
browser window is just a view of real data. It is just a snapshot, a
picture, a carbon copy, whatever analogy you want to use. It is not
real data. Real data is on the server, and it is controlled by a
certain lifecycle, transactions, etc. Server data reflects current
Model state, updated according to previous events. Rolling back Model
just because a user loads a stale view is like... I don't know, like
having again full tank of gas after you drove 100 miles and then
returned back to the gas station, where you had filled your car
earlier.

Well, it would be cool to have gas tank full again, but it goes
against all possible laws. Gas was used up, period. The same with
model: it had been changed. Another bad analogy: you found your dad's
pink glasses in the drawer and put them on. Should modern Toyotas be
replaced with old Talbots? Should all people wear bell-bottomed jeans?
Well no, because things do not change simply because you look at them
through old glasses.

End of day, so the analogies suck :) Anyway, you cannot save the
assignment because it was deleted, its PK was deleted too. If you want
to save a copy into a new assignment, that is a different story, but I
would be against of this, it is not intuitive for me. By the way, I
did "Copy" and "Save" (or just "Copy"?) and it worked. I am not sure
how I think about this, was correct or not ;-)

I understand that because this is a detached object you can save it
into a new database row, but I am not sure that this is intuitive.

Check this one of mine:
http://superinterface.com/strutsdialog/cruditemlist.do It actually has
a flaw: I forgot to mark pages as non-cachable. But whatever. Click
"Update Item", do something, then save or delete, you get to the list
again. Then click Back, you will see the stale page of the item. Then
click Save or Delete again and you will get either "Not Active Or
Expired" error or "Item XYZ could not be found in storage". It does
not look pretty for a user, I agree, but it reflects what really
happened with data. I don't know, maybe I am wrong with this
approach...

Michael.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to