Hi, On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson <gar...@globalmentor.com> wrote:
> On 9/23/2014 12:08 PM, Martin Grigorov wrote: > >> On Tue, Sep 23, 2014 at 4:44 PM, Garret Wilson <gar...@globalmentor.com> >> wrote: >> >> OMG. What a sad email to wake up to. :( >>> >>> Let me let all that digest for a while. I never would have imagined a >>> situation this dire. Imagine if every time you went to Facebook, it >>> generated a new https://www.facebook.com/jdoe?124154451 version! So >>> basically Facebook could never use Wicket without rewriting the whole >>> page >>> caching scheme. Or >>> >> >> this particular url (https://www.facebook.com/jdoe?124154451) returns >> 404, >> but otherwise Facebook renders completely different content on page >> refresh >> (and I'm OK with that!) >> > > Ah, I wasn't clear. I meant, imagine if Facebook was running on Wicket. > Each time you go to https://www.facebook.com/jdoe, it would redirect you > to https://www.facebook.com/jdoe?1. Imagine if you went there again and > it redirected you to https://www.facebook.com/jdoe?2. Imagine if you > clicked "Like" on somebody's picture, and it redirectred you to > https://www.facebook.com/jdoe?3. But it still kept > https://www.facebook.com/jdoe?2 in memory, so that when you hit "Back" > you'd see the picture before you liked it. Soon you'd have > https://www.facebook.com/jdoe?124154451... > > What is the actual problem ? >> The number in the url ? >> > > Yes. > > Or that a new page instance is created ? >> > > ...and yes. > > And both of those together cause even more problems, because not only are > new page instances created, the user can navigate among them. > > I'm not denying that versioned pages may be a useful concept for some use > cases (even though I can't think of any offhand). I'm just saying it's not > my use case, and I had assumed throughout development on our project that I > could just turn it off by calling setVersioned(false). Your email this > morning informed me that I had been under an incorrect assumption, and that > made me sad. > > > >> Imagine this: >> PageA initial state renders PanelA and a LinkA. >> Clicking on LinkA PanelA is replaced with PanelB. >> >> case 1) with the pageId in the url if you refresh the page then you will >> still see PanelB in the page >> case 2) without the pageId you will see PanelA, because a new page >> instance >> is created >> >> Now imagine that Wicket stores pages by type. >> > > It's not necessarily by type---it's by mounted URL. Maybe you mount the > same type at various URLs; they would all be kept track of separately. This > is how Guise does it. (I'm not saying "Oh, Guise is better than > everything." I'm just using it as an example reference here. It does some > things better. It does some things worse. It functions like I'm describing > now because that's the only thing I thought of when I wrote it.) Each mount > point has a single version that is changed as the user interacts with it. > Granted, this causes some problems when multiple browser tabs are opened > with the same page; in the future I hope to address this, but it's not > trivial. Guise started out with the assumption that the user would only > have one tab opened for a page. > > But in this example, yeah, a Wicket page "type" equates to a single URL > mount point. I was being pedantic. > > > Once the user clicks LinkA >> how (s)he will be able to see the initial state with PanelA again ? >> > > Why would the user expect or want to see PanelA again? Didn't (s)he just > click on the link that said "remove panel A and add panel B?" If the user > wants to see PanelA again, (s)he clicks on the link that says "put panel A > back!" > > Apparently Wicket thinks the browser "back" button is an "undo" button. > But in my mind it's not---it's a "back" button that goes to the previous > page. If you're still on the same page but you've changed that page, then > you see the new version of the page! > This is not 100% correct. Going back will tell Wicket to load some previous page version. But it is your code logic that decides what to show. If you use dynamic model then you will ask the DB whether the current user is a friend with Jane Doe and it will return the current state of affairs. Wicket renders pages with cache disabled so #onConfigure, #onBeforeRender, #onRender, #onAfterRender, onDetach are called and your application logic decides what exactly to render. > > Imagine that you're on Facebook, and you click on the button that says > "unfriend Jane Doe" (that is, don't be friends anymore with Jane Doe). What > happens when you hit the back button? Do you expect to get Jane Doe back as > a friend? > > Hahahah! Sorry, please forgive me for laughing at my own example. It's > been a long, exhausting day---allow me a bit of humor before heading to bed. > Then sorry for spoiling your fun :-) > > Anyway, I hope you see my point. Like I said, maybe versioning has its use > cases. It's just not /my/ use case, and I want to turn it off. > I see your point. Another user recently also tried to explain similar needs like yours. > > Best, > > Garret >
