On extra thing I would as is that stale error pages are not always bad.
For some mission-critical banking applications it may be an EXCELLENT
idea to trap back buttons as stale pages and display a custom error page
warning the customer about the risks of using the application in this
way and then taking them back to a known starting point. What would be
call would be if the stale error page could take them back to a per-page
specifiable 'on stale page' rather than always the home page.
Chris Turner wrote:
Wow! I go away for one evening and its like an explosion in my mail
box ;)
First, I think the undo approach is an excellent one. Looks much
cleaner than the clone/copy one and will have much less scope for
coming back and biting us in the future. Some comments:
- I'm not sure you can just separate it as simply as value/reference.
As models are under control of the end developer I see no reason why
they would not create a detachable model but at some point change the
object that it was referencing. Thus when they press the back button
they have a page that is changing a different referenced object. We
have something similar in an app I'm currently working on in that one
page is a combined list/create/view/edit page so the page is the same
but the id of the referenced business object changes over time.
Solution: I think you have to clone the model in all undo cases.
- There are also some other options regarding staleness which we could
define against a page:
* In some cases if a page is detected as stale there is actually
no problem with just rendering the very latest version of the page. In
fact this is desirable in some cases, for example I might want my
shopping basket page to always show the latest basket contents so if
the user goes back to a stale shopping basket page I can just send in
return the latest page rendering instead.
* Another option might be that if a page is detected as stale then
you always return to an associated known starting page - e.g. a
summary page from which they can navigate forward again to the latest
area of data that they need to work with.
By having the four options per page: stale error, undo, render latest
and goto page we cover pretty much anything that most people would
want to do. The advantage of this is also that we only need capture
undo events for pages where this is specified as the mode (which is
quite important for efficient clustering). We may also need to do
something like specifying behaviour in relation to whether undo is
held in the session or not (i.e. clustered/session recovery undo) and
if not how the page should react - I'll put a post up on where I have
got with clustering later today.
regards,
Chris
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
