On 7/12/05, Johan Compagner <[EMAIL PROTECTED]> wrote: > Same thing for listviews. 1 page 2 renders: one with 10 elements and one > with 11. > When you go back to one it should restore that component state..
Ok, first of all, let's consider that I do not suggest to *change* current Wicket cycle. I just would like to have an alternative cycle, which would sync view with model instead of rolling back model to sync it with view. The point of Wicket is to be used, right? I want to use it, I like most of its ideas, a lot of thought went into it. But I would like it to have an option of behaving just a little differently ;) Now, what is the point of restoring stale view with 10 elements? That train has left long ago. You do not use the same approach with shopping cart, right? If shopping cart is payed for and disposed, you do not recreate it, if a user clicks Back? So, I want my app to behave as with shopping cart :) > I don't want to disable the back button > Back button should work that is how a browser work. > How all people that have used browsers are used to. I am not talking about disabling Back button. I am talking about not providing browser enough information to enable it :) If it enables it, whatever, it will be dealt with. But if we got a smart browser, than a user experience gets a whole lot easier and straightforward. Returning to my example: why do you need to click Back 5 times to return from login page, if you can do it only once? This is very logical and users get it immediately: login page, 5 attempts, did not work, go back from login page with one click. So easy, they even did not think about it. Also, what do you think user experience will be with widespread Ajax adoption? "Clean" URLs allow to have Ajax user experience using traditional request/response cycle. On 7/13/05, Matej Knopp <[EMAIL PROTECTED]> wrote: > Web application is not web pages. Returning to a page that's obsolete > and interacting with it doesn't seem to be the best way of using an > web-application to me. And from my experience, no dealing with back > button works 100% right. Even with cache-control and no-cache pragma, > the page doesn't get refreshed on every browser every time. And wicket > back button support is limited to the component's state. But what about > the actual data? Should I track every data manipulation and be able to > reconstruct it? I'm affraid that the complexity would be enormous. Exactly, *web apps are not hyperlinked documents*. the example with shopping cart above. With the approach that I advocate for, there are two cases (actually three): * First, if previous view belongs to the same web island, and you got smart browser, you would not be able to navigate to stale page at all. * Second, if previous view belongs to different web island, and you got "right" browser which reloads "no-cache, no-store" page on going back, then browser would sync view with server model, and you would see an error mesage, telling that data corresponding to that page is gone. Or, you would see a welcome/generic/more friendly page. * Third, if your browser does not reload a page and caches every view even from the same location, you would see a stale page. When you try to submit it, there are two choices: either to rollback app model and to sync it with page, or to check that app data expired, and to show error message. Back button is essential when you return back say, from reports page to item list page. No argument here. But if you are on reports page, and you have several controls, dropdowns, etc, to format the output. You selected settings that you like, they are stored on server. Then you click back *one time*, return to item list, choose another item and see report with settings you just made. Very intuitive. Back and Forward buttons should provide navigation between bookmarkable components. Everything else... if a browser shows every version of a page, it works your original way. If it shows only pages with distinct address, it works like web island. Application should be able to process input from stale page anyway, because browsers are different. Michael. ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
