ok but it has only started happening since I added the single-page-instance
code...
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/turning-off-page-versioning-tp4667631p4668679.html
Sent from the Users forum mailing list archive at Nabble.com
; page cause a StalePageException which results in a refresh but without the
> expected panel change normally caused by the link which is jarring..
>
> Any ideas?
>
> CN
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/turning-off-page-versioning-tp4
icket.1842946.n4.nabble.com/turning-off-page-versioning-tp4667631p4668677.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail:
The magic happens in WebPageRenderer#respond() method.
But beware that this is one of the most scary (to reason about) code in
Wicket. We know about this problem, we simplified it somehow for Wicket 7,
but still as the comments there say "it is hairy".
Martin Grigorov
Wicket Training and Consultin
One last question: what code is involved in the redirect to buffer
strategy? Where to start to search if using the NoVersionMapper without the
SinglePageManager will have problems with redirect to buffer?
Thanks a lot for your time so far. As always you rock (and so does the
list) :)
On Fri, Sep
Thanks for testing!
I'm sure there will be problems to be solved.
The app is just a proof of concept that it is not that hard to accomplish
what Garret wanted.
If someone wants to use this in production then (s)he will have to test and
optimize it further.
Martin Grigorov
Wicket Training and Consu
I just tried your demo, it does seem to redirect (the requested url is ?0
while the current url has no version number)...
But I was referring to the use of NoVersionMapper without
SinglePageManager. I tried this too, and redirect to render breaks because
the redirect is to http://blahblah/a and ha
On Fri, Sep 26, 2014 at 12:23 PM, mscoon wrote:
> Okay I see.
>
> I imagine this approach breaks if the render strategy is REDIRECT_TO_RENDER
> and works in ONE_PASS_RENDER and REDIRECT_TO_BUFFER.
>
Wicket will redirect only if the requested url differs with the response
url.
Since the ?pageId i
Okay I see.
I imagine this approach breaks if the render strategy is REDIRECT_TO_RENDER
and works in ONE_PASS_RENDER and REDIRECT_TO_BUFFER.
Also REDIRECT_TO_BUFFER works sort of by chance? What would happen if
somehow requests from different tabs for the same page (url) were handled
simultaneous
Hi,
What you describe is what several users currently do by using
NoVersionMapper.
NoVersionMapper is the thing that hides the ?pageId from the url in the
address bar.
The changes you suggest to be done in SinglePageManager (effectively remove
SinglePageManager completely) is the current default
Martin,
I found you "single-page-instance" sample very interesting.
I have the following question if you can spare some time:
What happens if you completely remove the local map in SinglePageManager
(and the associated) code?
I.e. if SinglePageManager#getPage(int id) always delegates to the
und
Garret,
Please take a look at https://github.com/martin-g/single-page-instance
- single page instance per class
- stateful
- no ?pageId in the url
I hope when your next application is bought by
Facebook/Microsoft/Amazon/... you say a good word about Apache Wicket ;-)
Martin Grigorov
Wicket Trai
On 24/09/2014 16:22, Garret Wilson wrote:
On 9/24/2014 9:26 AM, Martijn Dashorst wrote:
On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson
wrote:
I'm not denying that versioned pages may be a useful concept for
some use
cases (even though I can't think of any offhand).
Persioning is a very usefu
You could generally tune down on telling the world about your
emotional state on technical mailing lists, your emotional state is of
no significant interest to the people who registered to this mailing
list, at least no in the amount you provide. We got it the first time.
And e.g. your phrasing "Y
On 9/24/2014 11:18 AM, Martijn Dashorst wrote:
...
And ranting about how stupid we are for having page versions doesn't
help either.
Hey, wait a minute. Where did that come from? That sort of hurts my
feelings. I brought up this topic, and I've said throughout this
discussion that versioning
On 9/24/2014 9:26 AM, Martijn Dashorst wrote:
On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson wrote:
I'm not denying that versioned pages may be a useful concept for some use
cases (even though I can't think of any offhand).
Persioning is a very useful concept and used in many applications. You
There's probably a particular way of how we (at my €day job) develop
applications, but of all the problems our users report back to us,
none of them involve confusion about the back button behaviour. Either
our users don't know the back button exists, or they have become
accustomed to not using it
On Wed, Sep 24, 2014 at 3:30 PM, Nick Pratt wrote:
> Funny this thread appeared this week - I had a client question our
> forward/back navigation last Wednesday and we got into a fairly lengthy
> discussion about this specific topic. What came out of that was that their
> expectations of page na
On 9/24/2014 4:28 AM, Martin Grigorov wrote:
...
> Apparently Wicket thinks the browser "back" button is an "undo" button.
> But in my mind it's not---it's a "back" button that goes to the previous
> page. If you're still on the same page but you've changed that page, then
> you see the new versi
Funny this thread appeared this week - I had a client question our
forward/back navigation last Wednesday and we got into a fairly lengthy
discussion about this specific topic. What came out of that was that their
expectations of page navigation in a webapp vs a desktop app are different
in today'
On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson wrote:
> I'm not denying that versioned pages may be a useful concept for some use
> cases (even though I can't think of any offhand).
Persioning is a very useful concept and used in many applications. You
are just focussing on your particular use ca
No, I believe what Wicket currently does is okay, but in web projects
with wicket, when page versioning is a problem (e.g. because of the
number apearing in the url, or any other issue with it), then it is
commonly dealt with much too late.
Too late means that application pages will already be fil
Thibault,
On Wed, Sep 24, 2014 at 11:23 AM, Thibault Kruse
wrote:
> On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson
> wrote:
> > I'm not denying that versioned pages may be a useful concept for some use
> > cases (even though I can't think of any offhand). I'm just saying it's
> not
> > my use c
On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson wrote:
> I'm not denying that versioned pages may be a useful concept for some use
> cases (even though I can't think of any offhand). I'm just saying it's not
> my use case, and I had assumed throughout development on our project that I
> could just
Hi,
On Wed, Sep 24, 2014 at 2:13 AM, Garret Wilson
wrote:
> On 9/23/2014 12:08 PM, Martin Grigorov wrote:
>
>> On Tue, Sep 23, 2014 at 4:44 PM, Garret Wilson
>> wrote:
>>
>> OMG. What a sad email to wake up to. :(
>>>
>>> Let me let all that digest for a while. I never would have imagined a
>>
On 9/23/2014 12:08 PM, Martin Grigorov wrote:
On Tue, Sep 23, 2014 at 4:44 PM, Garret Wilson
wrote:
OMG. What a sad email to wake up to. :(
Let me let all that digest for a while. I never would have imagined a
situation this dire. Imagine if every time you went to Facebook, it
generated a new
It is true that page version does seem kind of redundant or even annoying
at times. If you have a wicket app that is full ajax (remember that ajax
requests don't increment the page version), the only reason you need the
page version is so you can have the same page open in two different tabs
with d
On Tue, Sep 23, 2014 at 4:44 PM, Garret Wilson
wrote:
> OMG. What a sad email to wake up to. :(
>
> Let me let all that digest for a while. I never would have imagined a
> situation this dire. Imagine if every time you went to Facebook, it
> generated a new https://www.facebook.com/jdoe?124154451
It is an interesting question whether other web frameworks (also
outside JVM world) use any similar page versioning scheme to wicket. I
am not aware of any.
In any case I guess most projects using wicket would have to make
design decisions based on whether the page version is acceptable in
the URL
In our project we are using NoVersionRequestMapper to create user friendly
URLs
seems to work as expected
On 23 September 2014 20:44, Garret Wilson wrote:
> OMG. What a sad email to wake up to. :(
>
> Let me let all that digest for a while. I never would have imagined a
> situation this dire. Im
OMG. What a sad email to wake up to. :(
Let me let all that digest for a while. I never would have imagined a
situation this dire. Imagine if every time you went to Facebook, it
generated a new https://www.facebook.com/jdoe?124154451 version! So
basically Facebook could never use Wicket withou
Hi,
In short, to accomplish all this you will need several custom impls of
Wicket interfaces.
1) custom IRequestMapper that just ignores PageInfo when generating the url
for IPageRequestHandler. Search in the archives for "NoVersionRequestMapper"
2) a completely new IPageManager (interface!) that
Can someone explain to me exactly how page versioning works, and how to
turn it off?
I have a page StagingPage that contains a file uploader. This page is
interesting in that when you upload some files with Button1, the page
lists the files on the page and keeps them in a collection until you
33 matches
Mail list logo
