@Bertrand Thank you for clarifying that ALL urls in this discussion
are mapped to the same page class.
@Igor The core of Wicket value proposition is that it manages the
state of your pages correctly. So, verifying that the state that
Wicket manages is consistent with user inputs (product id 123 vs
https://issues.apache.org/jira/browse/WICKET-4441
now I'm convinced that this additional check is needed there
On Fri, Apr 13, 2012 at 12:00 AM, Igor Vaynberg wrote:
> in that case a bit of logic in the page that checks the product id in
> onconfigure() against one in the model, and if they are d
in that case a bit of logic in the page that checks the product id in
onconfigure() against one in the model, and if they are different
redirects to the correct page...
-igor
On Thu, Apr 12, 2012 at 1:56 PM, Bertrand Guay-Paquet
wrote:
>> you simply need to check what page class is mounted, and
you simply need to check what page class is mounted, and if the page
retrieved by id is not of that class then dont render it but redirect
to the bookmarkable url instead.
-igor
Both pages actually use the same MyPage.java class in this case. The
only difference is the page parameter encoded in
On Thu, Apr 12, 2012 at 10:39 AM, Martin Grigorov wrote:
> On Thu, Apr 12, 2012 at 7:47 PM, Bertrand Guay-Paquet
> 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 ver
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 wrote:
> "And I see no way to detect s
"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 wrote:
> On Thu, Apr 12, 2012 at 7:47 PM, Bertrand Guay-Paquet
> wrote:
>> I don't know much about HybridUrlCoding
On Thu, Apr 12, 2012 at 7:47 PM, Bertrand Guay-Paquet
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, bo
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
"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 wrote:
> On Thu, Apr 12, 2012 at 8:55 AM, Martin Grigorov wrote:
>> On Thu, Apr 1
On Thu, Apr 12, 2012 at 8:55 AM, Martin Grigorov wrote:
> On Thu, Apr 12, 2012 at 6:43 PM, Igor Vaynberg
> wrote:
>> On Thu, Apr 12, 2012 at 8:22 AM, Alec Swan wrote:
>>> Igor,
>>>
>>> The link I click ends with /mp/oid/123.9, where 123 is a product id.
>>> However, when the page is rendered it
On Thu, Apr 12, 2012 at 6:43 PM, Igor Vaynberg wrote:
> On Thu, Apr 12, 2012 at 8:22 AM, Alec Swan 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 eve
On Thu, Apr 12, 2012 at 8:22 AM, Alec Swan 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
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 wron
Hey Bertrand,
This is not a complete answer. The complete answer is in the mail
thread that led to WICKET-4488:
"Only the initial version of _stateful_ page is bookmarkable".
I.e. only ?0 is really bookmarkable because in my session page1?3
could be created by clicking link1 then link2 while in th
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 instanti
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 wrote:
> Hello,
>
> I received a link from a customer to a versioned page (.version at the
> end
17 matches
Mail list logo