Agreed. I'm looking forward to you comming to work for us next week.
We'll delve into this for sure!
Eelco
Jonathan Locke wrote:
i agree. back button is the most important feature of a browser.
this is why i went to such lengths to do stale page detection instead
of just disabling the back button entirely. making the back button
more function would be good. introducing a rats nest of model cloning
problems would not be.
we /will/ solve this issue. i'm just concerned about /how/ we solve it.
Eelco Hillenius wrote:
What we (Johan, I and some more guys over at Topicus) are worried
about is that it usually is really not acceptable to show an error
message (stale data) when the user works with the back button. It
sure is in the eyes of us techs, but it isn't in the eyes of the
average user we have to cope with.
Also, this is a new problem for us. We have been working with
frameworks like Struts, Maverick, Cocoon and even plain servlets/ jsp
etc for years, and as with these you are used to take care that you
can build up state from everything that comes in with the request,
you never had issues like these. Now, imagine us displaying the new
webapps we're working on... the very first thing one of our collegues
did - just by accident - is pushing the back button somewhere where
it shouldn't have been pushed (because he added an item to a list,
and wanted to see the details of another item again)... Wham! Stale
data page! So we start explaining them that this is our price of
progress. Well, you understand this collegue did not really agree
this was progress, especially because we never had this kind of
things happening in other applications.
All, and I say ALL other frameworks deal with this issue. I don't
know about Tapestry, but I understand that as it was a source of
inspiration for Wicket, Tapestry does mark pages stale. I also
understood that Tapestry manages state in a very different way, so I
don't know whether it has the same issues as we have.
But JSF and .NET work alike in that they provide client saving state
(which sometimes give our .NET devs pages of 1MB if they don't watch
out). This is optional too, but if you use server side state, you run
into problems with those frameworks as well. But they solve it if you
want it. And Echo simply puts your webapp in frames and effectively
disables the backbutton! So, this is definitively not to say that
they do it better than we do, but I want to stress that the back
button issue is an important issue.
If we're never going to clone/ copy/ create undo actions, I just
can't see how we can solve this at all, except for removing replace
and removeAll (yes I really think they are the same in what problems
they represent) and thus forcing users to develop in a page based
manner. This might be the ultimate solution, but it would also reduce
the ability to write reusable components greatly.
I understand, and share, the gut feeling you have against any form of
cloning in Wicket. Therefore, I think we should really agree all on
this before we put it in any version at all. But, and I have made
this an issue a couple of times before, SUPPORTING THE BACKBUTTON IS
REALLY IMPORTANT.
What we came up with is probably not the perfect solution as it was
our first cut at it (though we had offline discussions about it for
months). But please take it as a starting point for working to a real
solution instead of just postponing it.
Eelco
this is a fundamental problem with browsers and back buttons that
isn't going away and wicket solves this problem. as i mentioned in
an earlier email to someone else, we can do a better job of marking
pages stale (right now we're marking more pages stale than need to
be), but the pages really /are/ stale because the markup no longer
matches the model that the markup wants to edit.
-------------------------------------------------------
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
-------------------------------------------------------
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
