I reproduced the issue in the quickstart attached to WICKET-4488.
On 04/04/2012 3:44 PM, Martin Grigorov wrote:
Hi Bertrand,
Did you verify that ? If yes and you have a quickstart then create a ticket.
There are no tickets from this discussion so far.
On Wed, Apr 4, 2012 at 6:31 PM, Bertrand Guay-Paquet
<ber...@step.polymtl.ca> wrote:
Hi,
Is there a JIRA issue tracking this "render wrong page based on page
version" problem? I'm very interested in this issue since sharing links to
stateful pages containing a page version is essentially broken.
Regards,
Bertrand
On 20/03/2012 12:45 PM, Igor Vaynberg wrote:
On Tue, Mar 20, 2012 at 8:52 AM, Martin Grigorov<mgrigo...@apache.org>
wrote:
On Tue, Mar 20, 2012 at 5:42 PM, Igor Vaynberg<igor.vaynb...@gmail.com>
wrote:
On Tue, Mar 20, 2012 at 8:28 AM, Martin Grigorov<mgrigo...@apache.org>
wrote:
On Tue, Mar 20, 2012 at 5:20 PM, Igor Vaynberg<igor.vaynb...@gmail.com>
wrote:
On Tue, Mar 20, 2012 at 1:07 AM, Martin Grigorov<mgrigo...@apache.org>
wrote:
On Tue, Mar 20, 2012 at 12:55 AM, Igor
Vaynberg<igor.vaynb...@gmail.com> 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.
no. we should redirect to wicket/page?x when the user navigates away
from the mounted page.
so i go to /bar which is BarPage and end up on /bar?0. click a link
that does something to BarPage, so end up on /bar?1. click a link that
takes me to FooPage, at this point since the page does not match the
mount i should go to /wicket/page?3
Currently it works just as you described it. Or I don't understand you
well.
A quickstart will make it more clear :-)
My "ouch" was for something else - userA sends foo?5, but userB's ?5
is for BarPage and current PageProvider will silently return BarPage's
version5. It wont be FooPage!
hrm. yes. in a cleanroom quickstart that is indeed how it works. in
our prod app, for some reason, it just shows the other page on the old
page's mount. i will have to dig into that in our code base.
the quickstart does show what you have described above (showing the
old version of the page instead of creating a new one), but it also
does another interesting. when it redirects to the incorrect version
of the other page it also uses wicket/bookmarkable url instead of the
mount.
so when i am on /bar?4 and change 4 to 2 which is a version of FooPage
mounted on /foo i dont go to /foo?5 like i should, instead i go to
/wicket/bookmarkable/FooPage?2
-igor
-igor
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
<pointbreak+wicketst...@ml1.net> 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: 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
--
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
--
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