When re-rendering a page, can you parse the new request URL and make sure
all the parameters are the same as those used at construction? I don't
think Wicket saves the original parameters now, but maybe it should.

On Thu, Apr 12, 2012 at 12:15 PM, Alec Swan <alecs...@gmail.com> wrote:

> "And I see no way to detect such problem by having just the
> information encoded in the url"
> This is VERY scary!
>
> How do I fix this?
>
> On Thu, Apr 12, 2012 at 11:39 AM, Martin Grigorov <mgrigo...@apache.org>
> wrote:
> > On Thu, Apr 12, 2012 at 7:47 PM, Bertrand Guay-Paquet
> > <ber...@step.polymtl.ca> wrote:
> >> I don't know much about HybridUrlCodingStrategy since I use Wicket 1.5,
> but
> >> based on what you observed (.x changes on every render), I would say
> the x
> >> is the page version.
> >>
> >> I re-read your emails and if I understand correctly, both product 379
> and
> >> 123 use the same page class. If that is the case, I don't think
> WICKET-4488
> >> is the same problem. That issue concerns rendering a different *Page*
> class
> >> because of a page version id. In your case, the MyPage page class is the
> >> single page involved in both the wrong and right pages you see rendered.
> >
> > ^^This is what I tried to explain in my earlier mail.
> >
> > user1 visits /product/10.8 then goes to /product/20.9
> > later user2 sends /product/30.8 to user1
> > user1 opens /product/30.8 but actually sees product/10 because Wicket
> > loads page with id = 8 from the store ignoring the current request
> > parameter (10)
> >
> > So this is *not* covered by 4488!
> > And I see no way to detect such problem by having just the information
> > encoded in the url
> >
> >
> >>
> >> I suggest putting a break point or logging code in your page's
> constructor
> >> to check 1) if a new page is created or an old version is displayed and
> 2)
> >> if the page parameters are properly decoded.
> >>
> >>
> >> On 12/04/2012 12:32 PM, Alec Swan wrote:
> >>>
> >>> "but because of the existence of a page with pageId 0 in the page
> >>> store user sees page1, not page2 as user2 intended"
> >>>
> >>> So, what is the page id in ../mp/oid/123.9 url?
> >>>
> >>>
> >>> On Thu, Apr 12, 2012 at 9:58 AM, Igor Vaynberg<igor.vaynb...@gmail.com
> >
> >>>  wrote:
> >>>>
> >>>> On Thu, Apr 12, 2012 at 8:55 AM, Martin Grigorov<mgrigo...@apache.org
> >
> >>>>  wrote:
> >>>>>
> >>>>> On Thu, Apr 12, 2012 at 6:43 PM, Igor Vaynberg<
> igor.vaynb...@gmail.com>
> >>>>>  wrote:
> >>>>>>
> >>>>>> On Thu, Apr 12, 2012 at 8:22 AM, Alec Swan<alecs...@gmail.com>
>  wrote:
> >>>>>>>
> >>>>>>> Igor,
> >>>>>>>
> >>>>>>> The link I click ends with /mp/oid/123.9, where 123 is a product
> id.
> >>>>>>> However, when the page is rendered its URL changes to end with
> >>>>>>> /mp/oid/123.x where x is different every time. Moreover, the page
> is
> >>>>>>> displaying the wrong product 379!
> >>>>>>>
> >>>>>>> So, it's not the wrong version of the page, but the wrong product
> that
> >>>>>>> worries me.
> >>>>>>>
> >>>>>>> Can you explain this?
> >>>>>>
> >>>>>> i never once said the word "version" in my response :) i was, in
> fact,
> >>>>>> talking about page ids. i dont think the old hybrid url coding
> >>>>>> strategy checks the page id in its url against the mount. so in your
> >>>>>> session page 9 can be something entirely different. i believe this
> is
> >>>>>> what was fixed by WICKET-4488.
> >>>>>
> >>>>> Not exactly.
> >>>>> 4488 fixes the problem when user1 has opened page1?0. Then user2
> sends
> >>>>> a url page2?0 to user1.
> >>>>> user1 opens this url but because of the existence of a page with
> >>>>> pageId 0 in the page store user sees page1, not page2 as user2
> >>>>> intended.
> >>>>>
> >>>>> After 4488 Wicket will load page with id == 0 then it will check its
> >>>>> class against the class of the mountPoint and ignore the stored page
> >>>>> if they don't match. And will create a completely new instance of
> >>>>> mountPoint and show it to user1. I.e. a new instance of page2
> >>>>>
> >>>>> I hope I described it clearly.
> >>>>
> >>>> i think thats *exactly* what i said...
> >>>>
> >>>>>
> >>>>>> -igor
> >>>>>>
> >>>>>>
> >>>>>>> Thanks,
> >>>>>>>
> >>>>>>> Alec
> >>>>>>>
> >>>>>>> On Wed, Apr 11, 2012 at 4:08 PM, Bertrand Guay-Paquet
> >>>>>>> <ber...@step.polymtl.ca>  wrote:
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> A ticket regarding this was created and resolved in 1.5
> >>>>>>>> (WICKET-4488). From
> >>>>>>>> the work log:
> >>>>>>>> "There was code for this situation but it didn't cover the case
> 100%.
> >>>>>>>> Now if a request to page2?0 is made and the type of the found page
> >>>>>>>> with id=0
> >>>>>>>> is not Page2 then a new instance of Page2 is instantiated."
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 11/04/2012 5:56 PM, Igor Vaynberg wrote:
> >>>>>>>>>
> >>>>>>>>> page 5 in your session can be completely different then page 5 in
> >>>>>>>>> user's session.
> >>>>>>>>>
> >>>>>>>>> non-bookmarkable urls cannot be emailed...thats kind of the
> point.
> >>>>>>>>>
> >>>>>>>>> -igor
> >>>>>>>>>
> >>>>>>>>> On Wed, Apr 11, 2012 at 2:37 PM, Alec Swan<alecs...@gmail.com>
> >>>>>>>>>  wrote:
> >>>>>>>>>>
> >>>>>>>>>> Hello,
> >>>>>>>>>>
> >>>>>>>>>> I received a link from a customer to a versioned page (.version
> at
> >>>>>>>>>> the
> >>>>>>>>>> end of the URL). However, when I click on the link I see a
> >>>>>>>>>> completely
> >>>>>>>>>> different page.
> >>>>>>>>>>
> >>>>>>>>>> We are using Wicket 1.4.17 and the page is mounted  as:
> >>>>>>>>>>
> >>>>>>>>>> mount(new HybridUrlCodingStrategy("mp", MyPage.class));
> >>>>>>>>>>
> >>>>>>>>>> Why is this happening and how can I fix this?
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>>
> >>>>>>>>>> Alec
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>>>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Martin Grigorov
> >>>>> jWeekend
> >>>>> Training, Consulting, Development
> >>>>> http://jWeekend.com
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>>>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >
> >
> >
> > --
> > Martin Grigorov
> > jWeekend
> > Training, Consulting, Development
> > http://jWeekend.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Reply via email to