On Tue, Mar 20, 2012 at 5:20 PM, Igor Vaynberg <[email protected]> wrote: > On Tue, Mar 20, 2012 at 1:07 AM, Martin Grigorov <[email protected]> wrote: >> On Tue, Mar 20, 2012 at 12:55 AM, Igor Vaynberg <[email protected]> >> wrote: >>> indeed. we should check that the page pointed to by the id maps back >>> to the mount, and create a new instance based on the mount if it >>> doesnt. jira please. >> >> This is already the case, no need of a ticket for this. If there is no >> ?5 then Wicket creates ?0 and shows it. > > this is not what i was talking about... > >> The "problem" Pointbreak actually mean is that userA may have opened >> ?5 in his session, copy the url and give it to >> userB, but userB also already have its own session and by chance he >> also had reached ?5 and these two ?5s are >> different because they may have different states for both users. > > not only are ?5 different, but they are entirely different pages. > > so user A goes to /foo, we redirect to /foo?0, they click around and > end up on /foo?2 > user B goes to /bar, we redirect to /bar?0, they click around and end > up on /bar?7 > > now user A emails user B the /foo?2 link. when user B hits that link > they end up going to a previous version of their *bar* page instead of > some instance of /foo because we do not check the mount vs the page > id, and whats worse we keep the mount in the url even though we are > displaying a page that is not mounted.
Ouch! > > i guess this is why in 1.4 we dropped the mount from nonbookmarkable urls... I hope you don't mean that we have to redirect to wicket/page?0 from the bookmarkable url that the user requested. It'd be better if we check the type of the stored page against the type of the page that is mounted at this "bookmarkable" url and throw PageExpiredException if they don't match. > > -igor > > > > >> >> The confusing part here is "bookmarkable". Now imagine that there is >> no ?pageId in the url. userA clicks several Ajax links to get to >> version5 of that page and then copy/paste the url but userB will see >> the initial state of the page, not version5 that userA actually meant. >> So it seems only ?0 is actually "bookmarkable" for stateful pages. >> Only in this case both users will see the same content (if there is no >> special logic for user permissions involved). >> >> If userA wants to fully share his page with userB then he has to share >> his session too, i.e. both ?5 and jessionid= has to be in the pasted >> url. I don't recomment this! >> >> ?5 helps when the user refreshes the page in his current session. In >> this case he will see the same content as before the refresh. In 1.4 >> he'd see the initial state of the page and will loose any state that >> is not persisted so far. >> >> >>> >>> -igor >>> >>> On Mon, Mar 19, 2012 at 3:52 PM, Pointbreak >>> <[email protected]> wrote: >>>> It's a problem when users bookmark it. Because ...?5 this session is an >>>> entirely other page as ...?5 in another session tomorrow. >>>> >>>> On Mon, Mar 19, 2012, at 11:53, Girts Ziemelis wrote: >>>>> >>>>> >>>>> On 2012-03-19 02:46, Paolo wrote: >>>>> > I support you! I implemented class NoVersionMount thanks to pointbreak >>>>> > in my MainApplication. And It will be my template for future app. But >>>>> > to do it, I needed to understood the problem, check on google, read a >>>>> > lot of pages, without found a solution, so post the question here, and >>>>> > after 3 post, got a right reply for me. Why an wicket user have to do >>>>> > all this???? Why not, wicket use the NoVersionMount as default Mount? >>>>> > Like in wicket 1.4. And implement an VersionMount as an alternative >>>>> > for developer? >>>>> I actually like this change so far. I can finally tell, that my page is >>>>> stetefull just by looking at the link and ask myself question - if I >>>>> really care so much about the clean link for this page, may be it should >>>>> be stateless in a first place? >>>>> >>>>> And why is ?0 such a big problem? It does not cause problems sending >>>>> links. >>>>> Is there any real proof of google indexing problems so far? >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> >> -- >> Martin Grigorov >> jWeekend >> Training, Consulting, Development >> http://jWeekend.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
