Yes, that makes more sense:
The page identifier takes precedence - if page ?8 is available it will
be shown to the user (given it has the correct type). The actual page
parameters don't matter.
IMHO this is a bug and you should create a Jira issue.
Sven
On 07/22/2013 03:44 PM, Peter Henderson wrote:
Hmm. My initial description is incorrect.
Alice sends /Order/123?8 to Bob.
Bob was recently looking at /Order/222?8
Bob shows a url of /Order/123?8 but is actually viewing /Order/222
I used 2 browsers (firefox+chromium) to reproduce.
I am using wicket 6.8
Should I be mounting the pages with some form of place holder to indicate I
am using index parameters?
Peter
On 22 July 2013 13:50, Sven Meier <[email protected]> wrote:
Hi,
I cannot reproduces the problem here, which Wicket version are you using?
Note that PageProvider#getStoredPage(**int) has a safety check to make
sure the page classes matches.
Sven
On 07/22/2013 01:38 PM, Peter Henderson wrote:
When a user emails a link to another user sometimes the wrong page is
rendered.
Alice sends
http://starjar.com/Part/123?**111 <http://starjar.com/Part/123?111>
to Bob who is was recently looking at
http://starjar.com/Order/456?**111 <http://starjar.com/Order/456?111>
Instead of seeing the part page he see the order page.
I assume this is because of the page version ?111 parameter.
The pages are mounted.
mountPage("/Order", classOf[OrderPage])
mountPage("/Part", classOf[PartPage])
and each page uses the page parameters to extract the id at index 0
def decode(parameters: PageParameters): Id = {
try {
val idValue = parameters.get(0).toInt;
....
Should I be mounting the pages differently to prevent the wicket page
revision version overriding the mount path?
------------------------------**------------------------------**---------
To unsubscribe, e-mail:
users-unsubscribe@wicket.**apache.org<[email protected]>
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
