Re: turning off page versioning

[Garret Wilson]

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 https://www.facebook.com/jdoe?124154451 version! So
basically Facebook could never use Wicket without rewriting the whole page
caching scheme. Or


this particular url (https://www.facebook.com/jdoe?124154451) returns 404,
but otherwise Facebook renders completely different content on page refresh
(and I'm OK with that!)


Ah, I wasn't clear. I meant, imagine if Facebook was running on Wicket. 
Each time you go to https://www.facebook.com/jdoe, it would redirect you 
to https://www.facebook.com/jdoe?1. Imagine if you went there again and 
it redirected you to https://www.facebook.com/jdoe?2. Imagine if you 
clicked "Like" on somebody's picture, and it redirectred you to 
https://www.facebook.com/jdoe?3. But it still kept 
https://www.facebook.com/jdoe?2 in memory, so that when you hit "Back" 
you'd see the picture before you liked it. Soon you'd have 
https://www.facebook.com/jdoe?124154451...



What is the actual problem ?
The number in the url ?


Yes.


Or that a new page instance is created ?


...and yes.

And both of those together cause even more problems, because not only 
are new page instances created, the user can navigate among them.


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 turn it off by calling setVersioned(false). 
Your email this morning informed me that I had been under an incorrect 
assumption, and that made me sad.





Imagine this:
PageA initial state renders PanelA and a LinkA.
Clicking on LinkA PanelA is replaced with PanelB.

case 1) with the pageId in the url if you refresh the page then you will
still see PanelB in the page
case 2) without the pageId you will see PanelA, because a new page instance
is created

Now imagine that Wicket stores pages by type.


It's not necessarily by type---it's by mounted URL. Maybe you mount the 
same type at various URLs; they would all be kept track of separately. 
This is how Guise does it. (I'm not saying "Oh, Guise is better than 
everything." I'm just using it as an example reference here. It does 
some things better. It does some things worse. It functions like I'm 
describing now because that's the only thing I thought of when I wrote 
it.) Each mount point has a single version that is changed as the user 
interacts with it. Granted, this causes some problems when multiple 
browser tabs are opened with the same page; in the future I hope to 
address this, but it's not trivial. Guise started out with the 
assumption that the user would only have one tab opened for a page.


But in this example, yeah, a Wicket page "type" equates to a single URL 
mount point. I was being pedantic.




  Once the user clicks LinkA
how (s)he will be able to see the initial state with PanelA again ?


Why would the user expect or want to see PanelA again? Didn't (s)he just 
click on the link that said "remove panel A and add panel B?" If the 
user wants to see PanelA again, (s)he clicks on the link that says "put 
panel A back!"


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 version of the page!


Imagine that you're on Facebook, and you click on the button that says 
"unfriend Jane Doe" (that is, don't be friends anymore with Jane Doe). 
What happens when you hit the back button? Do you expect to get Jane Doe 
back as a friend?


Hahahah! Sorry, please forgive me for laughing at my own example. It's 
been a long, exhausting day---allow me a bit of humor before heading to bed.


Anyway, I hope you see my point. Like I said, maybe versioning has its 
use cases. It's just not /my/ use case, and I want to turn it off.


Best,

Garret

Re: turning off page versioning

[mscoon]

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 different state.

If having the same page open multiple times with different state is
something not important for a particular application, then you may as well
not have a page version at all in the url...

As others have pointed out, I too think it would be nice if wicket could
support this out of the box (while at the same time making clear what the
drawbacks/limitations of this approach are).


On Tue, Sep 23, 2014 at 6:05 PM, Thibault Kruse 
wrote:

> 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 or not. There is no simple way of reasonably "switching it
> off" once an application has been created without giving this some
> thought.
>
> I don't think every web-framework should strive to be the best choice
> for facebook or similar, different frameworks may have different
> strengths and weaknesses (performance, memory-consumption,
> learning-curve, maintenance-costs, prototyping-speed, etc.)
>
>
> On Tue, Sep 23, 2014 at 3: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 version! So
> > basically Facebook could never use Wicket without rewriting the whole
> page
> > caching scheme. Or LinkedIn. Or... actually, come to think of it, I can't
> > even think of a single site that functions like Wicket, incrementing some
> > "page version" counter every time you interact with the page, so that you
> > can go back to other "versions". (Users don't want to go back to other
> > versions! They may want to go back to other /pages/ at different URLs,
> but
> > they realize that interacting with a single pages changes the state of
> that
> > page---they don't expect that other "versions" are kept around
> somewhere.)
> >
> > Continuing my scenario I outlined earlier, I have an HTML page called
> > MenuPage, which has ..., the
> target
> > page of which functions as I explained below. Every time the user goes to
> > the MenuPage and clicks on the link, you're saying that Wicket will
> generate
> > a new version of StagingPage in the cache, even with
> setVersioned(false)? It
> > will generate a new ...StagingPage.html?23423414 URL? There is no way to
> > turn that off... without essentially rewriting the whole Wicket page
> request
> > and caching mechanism??
> >
> > This is not good news. I'm not ranting, I'm crying.
> >
> > Garret
> >
> >
> > On 9/23/2014 8:24 AM, Martin Grigorov wrote:
> >>
> >> 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 works with
> Class
> >> instead of with Integer (pageId)
> >> So everytime a url is mapped to a page class you should use it to load
> the
> >> Page instance for this class
> >>
> >> In details:
> >> By design only stateless pages do not have the pageId in the url! If a
> >> request without pageId comes then a completely new page instance is
> >> created.
> >> By using something like NoVersionRequestMapper (not supported
> officially!)
> >> only the url for the browser address bar will miss the pageId (see
> >> PageAndComponentInfo class), but the pageId is in all link/form urls so
> >> clicking/submitting still works. But if the user refreshes the page (F5)
> >> then the state is lost!
> >>
> >> About Page#setVersioned(boolean)
> >> This tells Wicket to not increment the pageId after an interaction with
> >> the
> >> page. A pageId is associated with the page when it is instantiated, but
> >> any
> >> link click, form submit, etc. won't create a new version of the page.
> The
> >> final result is that every interaction (i.e. state change) with the page
> >> will lead to overriding the old one in the page stores.
> >> Wicket's IPageStore/IDataStore use API like: put(String sessionId, int
> >> pageId, byte[] serializedPage). At the end of every request cycle all
> >> rendered stateful pages are stored. If the pageId doesn't change then
> some
> >> old serializedPage would be overriden.
> >>
> >> For your requirements you will need an API like: put(String sessionId,
> >> Class pageClass, byte[] serializedPage

Re: turning off page versioning

[Martin Grigorov]

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 version! So
> basically Facebook could never use Wicket without rewriting the whole page
> caching scheme. Or


this particular url (https://www.facebook.com/jdoe?124154451) returns 404,
but otherwise Facebook renders completely different content on page refresh
(and I'm OK with that!)


> LinkedIn. Or... actually, come to think of it, I can't even think of a
> single site that functions like Wicket, incrementing some "page version"
> counter every time you interact with the page, so that you can go back to
> other "versions". (Users don't want to go back to other versions! They may
> want to go back to other /pages/ at different URLs, but they realize that
> interacting with a single pages changes the state of that page---they don't
> expect that other "versions" are kept around somewhere.)
>

IPageSettings#setVersioned(false) disables the state management for all
pages in an application


>
> Continuing my scenario I outlined earlier, I have an HTML page called
> MenuPage, which has ..., the target
> page of which functions as I explained below. Every time the user goes to
> the MenuPage and clicks on the link, you're saying that Wicket will
> generate a new version of StagingPage in the cache, even with
> setVersioned(false)? It will generate a new ...StagingPage.html?23423414
> URL? There is no way to turn that off... without essentially rewriting the
> whole Wicket page request and caching mechanism??
>

What is the actual problem ?
The number in the url ?
Or that a new page instance is created ?


>
> This is not good news. I'm not ranting, I'm crying.


Imagine this:
PageA initial state renders PanelA and a LinkA.
Clicking on LinkA PanelA is replaced with PanelB.

case 1) with the pageId in the url if you refresh the page then you will
still see PanelB in the page
case 2) without the pageId you will see PanelA, because a new page instance
is created

Now imagine that Wicket stores pages by type. Once the user clicks LinkA
how (s)he will be able to see the initial state with PanelA again ?



>
>
> Garret
>
>
> On 9/23/2014 8:24 AM, Martin Grigorov wrote:
>
>> 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 works with Class
>> instead of with Integer (pageId)
>> So everytime a url is mapped to a page class you should use it to load the
>> Page instance for this class
>>
>> In details:
>> By design only stateless pages do not have the pageId in the url! If a
>> request without pageId comes then a completely new page instance is
>> created.
>> By using something like NoVersionRequestMapper (not supported officially!)
>> only the url for the browser address bar will miss the pageId (see
>> PageAndComponentInfo class), but the pageId is in all link/form urls so
>> clicking/submitting still works. But if the user refreshes the page (F5)
>> then the state is lost!
>>
>> About Page#setVersioned(boolean)
>> This tells Wicket to not increment the pageId after an interaction with
>> the
>> page. A pageId is associated with the page when it is instantiated, but
>> any
>> link click, form submit, etc. won't create a new version of the page. The
>> final result is that every interaction (i.e. state change) with the page
>> will lead to overriding the old one in the page stores.
>> Wicket's IPageStore/IDataStore use API like: put(String sessionId, int
>> pageId, byte[] serializedPage). At the end of every request cycle all
>> rendered stateful pages are stored. If the pageId doesn't change then some
>> old serializedPage would be overriden.
>>
>> For your requirements you will need an API like: put(String sessionId,
>> Class pageClass, byte[] serializedPage) and byte [] get(String
>> sessionId, Class pageClass).
>> You can create a IPageManager wrapper that maps sessionId+pageId to
>> pageClass and use that pageClass with custom IMyPageStore and IMyDataStore
>> impls. (Just an idea out of my mind.)
>>
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Tue, Sep 23, 2014 at 3:42 AM, Garret Wilson 
>> wrote:
>>
>>  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 hit
>>> Button2,
>>> at which point the pages does Some Other Really Interesting 

Re: turning off page versioning

[Thibault Kruse]

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 or not. There is no simple way of reasonably "switching it
off" once an application has been created without giving this some
thought.

I don't think every web-framework should strive to be the best choice
for facebook or similar, different frameworks may have different
strengths and weaknesses (performance, memory-consumption,
learning-curve, maintenance-costs, prototyping-speed, etc.)


On Tue, Sep 23, 2014 at 3: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 version! So
> basically Facebook could never use Wicket without rewriting the whole page
> caching scheme. Or LinkedIn. Or... actually, come to think of it, I can't
> even think of a single site that functions like Wicket, incrementing some
> "page version" counter every time you interact with the page, so that you
> can go back to other "versions". (Users don't want to go back to other
> versions! They may want to go back to other /pages/ at different URLs, but
> they realize that interacting with a single pages changes the state of that
> page---they don't expect that other "versions" are kept around somewhere.)
>
> Continuing my scenario I outlined earlier, I have an HTML page called
> MenuPage, which has ..., the target
> page of which functions as I explained below. Every time the user goes to
> the MenuPage and clicks on the link, you're saying that Wicket will generate
> a new version of StagingPage in the cache, even with setVersioned(false)? It
> will generate a new ...StagingPage.html?23423414 URL? There is no way to
> turn that off... without essentially rewriting the whole Wicket page request
> and caching mechanism??
>
> This is not good news. I'm not ranting, I'm crying.
>
> Garret
>
>
> On 9/23/2014 8:24 AM, Martin Grigorov wrote:
>>
>> 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 works with Class
>> instead of with Integer (pageId)
>> So everytime a url is mapped to a page class you should use it to load the
>> Page instance for this class
>>
>> In details:
>> By design only stateless pages do not have the pageId in the url! If a
>> request without pageId comes then a completely new page instance is
>> created.
>> By using something like NoVersionRequestMapper (not supported officially!)
>> only the url for the browser address bar will miss the pageId (see
>> PageAndComponentInfo class), but the pageId is in all link/form urls so
>> clicking/submitting still works. But if the user refreshes the page (F5)
>> then the state is lost!
>>
>> About Page#setVersioned(boolean)
>> This tells Wicket to not increment the pageId after an interaction with
>> the
>> page. A pageId is associated with the page when it is instantiated, but
>> any
>> link click, form submit, etc. won't create a new version of the page. The
>> final result is that every interaction (i.e. state change) with the page
>> will lead to overriding the old one in the page stores.
>> Wicket's IPageStore/IDataStore use API like: put(String sessionId, int
>> pageId, byte[] serializedPage). At the end of every request cycle all
>> rendered stateful pages are stored. If the pageId doesn't change then some
>> old serializedPage would be overriden.
>>
>> For your requirements you will need an API like: put(String sessionId,
>> Class pageClass, byte[] serializedPage) and byte [] get(String
>> sessionId, Class pageClass).
>> You can create a IPageManager wrapper that maps sessionId+pageId to
>> pageClass and use that pageClass with custom IMyPageStore and IMyDataStore
>> impls. (Just an idea out of my mind.)
>>
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Tue, Sep 23, 2014 at 3:42 AM, Garret Wilson 
>> wrote:
>>
>>> 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 hit
>>> Button2,
>>> at which point the pages does Some Other Really Interesting Thing with
>>> the
>>> files. In other words, the page acts like a staging area for files,
>>> allowing you to 1) upload files and then 2) d

Re: turning off page versioning

[Maxim Solodovnik]

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. 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 without rewriting the whole page
> caching scheme. Or LinkedIn. Or... actually, come to think of it, I can't
> even think of a single site that functions like Wicket, incrementing some
> "page version" counter every time you interact with the page, so that you
> can go back to other "versions". (Users don't want to go back to other
> versions! They may want to go back to other /pages/ at different URLs, but
> they realize that interacting with a single pages changes the state of that
> page---they don't expect that other "versions" are kept around somewhere.)
>
> Continuing my scenario I outlined earlier, I have an HTML page called
> MenuPage, which has ..., the target
> page of which functions as I explained below. Every time the user goes to
> the MenuPage and clicks on the link, you're saying that Wicket will
> generate a new version of StagingPage in the cache, even with
> setVersioned(false)? It will generate a new ...StagingPage.html?23423414
> URL? There is no way to turn that off... without essentially rewriting the
> whole Wicket page request and caching mechanism??
>
> This is not good news. I'm not ranting, I'm crying.
>
> Garret
>
> On 9/23/2014 8:24 AM, Martin Grigorov wrote:
>
>> 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 works with Class
>> instead of with Integer (pageId)
>> So everytime a url is mapped to a page class you should use it to load the
>> Page instance for this class
>>
>> In details:
>> By design only stateless pages do not have the pageId in the url! If a
>> request without pageId comes then a completely new page instance is
>> created.
>> By using something like NoVersionRequestMapper (not supported officially!)
>> only the url for the browser address bar will miss the pageId (see
>> PageAndComponentInfo class), but the pageId is in all link/form urls so
>> clicking/submitting still works. But if the user refreshes the page (F5)
>> then the state is lost!
>>
>> About Page#setVersioned(boolean)
>> This tells Wicket to not increment the pageId after an interaction with
>> the
>> page. A pageId is associated with the page when it is instantiated, but
>> any
>> link click, form submit, etc. won't create a new version of the page. The
>> final result is that every interaction (i.e. state change) with the page
>> will lead to overriding the old one in the page stores.
>> Wicket's IPageStore/IDataStore use API like: put(String sessionId, int
>> pageId, byte[] serializedPage). At the end of every request cycle all
>> rendered stateful pages are stored. If the pageId doesn't change then some
>> old serializedPage would be overriden.
>>
>> For your requirements you will need an API like: put(String sessionId,
>> Class pageClass, byte[] serializedPage) and byte [] get(String
>> sessionId, Class pageClass).
>> You can create a IPageManager wrapper that maps sessionId+pageId to
>> pageClass and use that pageClass with custom IMyPageStore and IMyDataStore
>> impls. (Just an idea out of my mind.)
>>
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Tue, Sep 23, 2014 at 3:42 AM, Garret Wilson 
>> wrote:
>>
>>  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 hit
>>> Button2,
>>> at which point the pages does Some Other Really Interesting Thing with
>>> the
>>> files. In other words, the page acts like a staging area for files,
>>> allowing you to 1) upload files and then 2) do something with them.
>>>
>>> I get this number on the end of the URLs which, from the page versioning
>>> and caching reference documentation >> guide/guide/versioningCaching.html>, seems to indicate the version of
>>> the
>>> page. I don't want this. I just want there to be one version of the page
>>> (even though it is stateful). The back button can go to the previous
>>> page;
>>> I don't care.
>>>
>>> So I turn off versioning in StagingPage with:
>>>
>>> setVersioned(false);
>>>
>>>
>>> But I still get numbers at the end of the StagingPage URL. Wor

ListView constructor signature was changed

[Maxim Solodovnik]

Hello All,

As I can see ListView constructor signature was changed since 7.0.0-M3
it is now
public ListView(final String id, final IModel> model)
public ListView(final String id, final List list)

was
public ListView(final String id, final IModel>
model)
public ListView(final String id, final List list)

right now it is impossible to pass List to listview
Can this change be reverted? Or is there any workaround?

-- 
WBR
Maxim aka solomax

Re: turning off page versioning

[Garret Wilson]

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 without rewriting the whole 
page caching scheme. Or LinkedIn. Or... actually, come to think of it, I 
can't even think of a single site that functions like Wicket, 
incrementing some "page version" counter every time you interact with 
the page, so that you can go back to other "versions". (Users don't want 
to go back to other versions! They may want to go back to other /pages/ 
at different URLs, but they realize that interacting with a single pages 
changes the state of that page---they don't expect that other "versions" 
are kept around somewhere.)


Continuing my scenario I outlined earlier, I have an HTML page called 
MenuPage, which has ..., the 
target page of which functions as I explained below. Every time the user 
goes to the MenuPage and clicks on the link, you're saying that Wicket 
will generate a new version of StagingPage in the cache, even with 
setVersioned(false)? It will generate a new ...StagingPage.html?23423414 
URL? There is no way to turn that off... without essentially rewriting 
the whole Wicket page request and caching mechanism??


This is not good news. I'm not ranting, I'm crying.

Garret

On 9/23/2014 8:24 AM, Martin Grigorov wrote:

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 works with Class
instead of with Integer (pageId)
So everytime a url is mapped to a page class you should use it to load the
Page instance for this class

In details:
By design only stateless pages do not have the pageId in the url! If a
request without pageId comes then a completely new page instance is created.
By using something like NoVersionRequestMapper (not supported officially!)
only the url for the browser address bar will miss the pageId (see
PageAndComponentInfo class), but the pageId is in all link/form urls so
clicking/submitting still works. But if the user refreshes the page (F5)
then the state is lost!

About Page#setVersioned(boolean)
This tells Wicket to not increment the pageId after an interaction with the
page. A pageId is associated with the page when it is instantiated, but any
link click, form submit, etc. won't create a new version of the page. The
final result is that every interaction (i.e. state change) with the page
will lead to overriding the old one in the page stores.
Wicket's IPageStore/IDataStore use API like: put(String sessionId, int
pageId, byte[] serializedPage). At the end of every request cycle all
rendered stateful pages are stored. If the pageId doesn't change then some
old serializedPage would be overriden.

For your requirements you will need an API like: put(String sessionId,
Class pageClass, byte[] serializedPage) and byte [] get(String
sessionId, Class pageClass).
You can create a IPageManager wrapper that maps sessionId+pageId to
pageClass and use that pageClass with custom IMyPageStore and IMyDataStore
impls. (Just an idea out of my mind.)


Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Tue, Sep 23, 2014 at 3:42 AM, Garret Wilson 
wrote:


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 hit Button2,
at which point the pages does Some Other Really Interesting Thing with the
files. In other words, the page acts like a staging area for files,
allowing you to 1) upload files and then 2) do something with them.

I get this number on the end of the URLs which, from the page versioning
and caching reference documentation , seems to indicate the version of the
page. I don't want this. I just want there to be one version of the page
(even though it is stateful). The back button can go to the previous page;
I don't care.

So I turn off versioning in StagingPage with:

setVersioned(false);


But I still get numbers at the end of the StagingPage URL. Worse, back and
forward in my browser goes between apparently two versions of the page (one
with the "Choose Files" button selecting files, and one without)---but the
number in the URL doesn't change! Worse still, when I remove the number and
reload the URL without the number, Wicket puts the number back but first
increments the number! Now back and forward cycle between numbered URLs.

I thought setVersioned(false) was supposed to turn a

Url loading context twice

[Vishal Popat]

Hi,

I have a really strange one...
I am using 
Apache 2.x
Jboss 7 (EAP 6.3) and also tried in Tomcat 7
Wicket 6.16.0

I used the HelloWorld application here 
https://wicket.apache.org/learn/examples/helloworld.html

It works fine on http://localhost:8080/myapp

I add Apache virtual host with the following settings:


ServerName myapp.com

ProxyRequests Off
ProxyPreserveHost On
ProxyPassReverseCookiePath / /
ProxyPass / http://localhost:8080/myapp/
ProxyPassReverse / http://localhost:8080/myapp/


It works fine at the url http://localhost:8080/myapp and myapp.com

When I add the following to the HelloWorld.java file:

add(new Link("myLink") {
@Override
public void onClick() {
}
});

and the following in the HelloWorld.html
link

And load http://localhost:8080/myapp it works fine.

However, if I load myapp.com I get a 404 as the url is changed to
http://myapp.com/myapp/;jsessionid=4A80C86C4F4BF1FAE13721E22F64350E?0

The body of the 404 page says the following:
HTTP Status 404 - /myapp/myapp/;jsessionid=4A80C86C4F4BF1FAE13721E22F64350E
type Status report
message /myapp/myapp/;jsessionid=4A80C86C4F4BF1FAE13721E22F64350E
description The requested resource is not available.
Apache Tomcat/7.0.30

Does anyone have any idea why this is happening?

Regards
Vishal

Re: access to url at http 404

[Martin Grigorov]

Hi,

You can use
http://docs.oracle.com/javaee/7/api/javax/servlet/RequestDispatcher.html#ERROR_REQUEST_URI
to get the original uri.
It is stored as request attribute.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Tue, Sep 23, 2014 at 4:00 PM, Karl-Heinz Golz <
karl-heinz.g...@t-online.de> wrote:

> Hello,
>
> is it possible to get the incorrect url when error 404 occurs?
>
> I would like to inspect this url and react differently for
> - users who want access but did a mistake in the url or
>   bookmarked an url which is no longer valid
>   -> show StartPage (with some more functionality)
> - others who want to access through "brute-force" by adding garbage to
> the url
>   -> show a short error page
>
> I am using Wicket 6.17.0.
>
> many thanks in advance
> Karl-Heinz
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

access to url at http 404

[Karl-Heinz Golz]

Hello,

is it possible to get the incorrect url when error 404 occurs?

I would like to inspect this url and react differently for
- users who want access but did a mistake in the url or
  bookmarked an url which is no longer valid
  -> show StartPage (with some more functionality)
- others who want to access through "brute-force" by adding garbage to
the url
  -> show a short error page
 
I am using Wicket 6.17.0.

many thanks in advance
Karl-Heinz


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Request for re-opening a Jira issue

[Martin Grigorov]

See http://markmail.org/message/ofyvgybcjp5cvf75

You talk about the same idea.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Tue, Sep 16, 2014 at 12:10 PM, Bernard  wrote:

> Martin,
>
> First I appreciate very much your hard work in the mailing list and
> Jira space.
>
> Re 1. I accept this, but before developing ideas, I would want to
> reach some consensus that there is a chance of having some change
> implemented in wicket core.
>
> Re 2. The use case needs page state because it uses panel replacement
> where the last state must be the only available state. The previous
> state must be destroyed and not be available to the user even after
> reload. That is the whole point, the solution that solves the back
> button problem in this use case. I see from your comment that I did
> perhaps not explain the use case. But my dilemma is when I write too
> much about the use case, then I would lose the compactness and clarity
> of the issue. Of course there are potentially other solutions not
> involving page state but alternatively session state but these would
> depart from wicket patterns. I would feel more like programming Spring
> MVC or similar technologies lacking the power of Wicket.
>
> More below inline ...
>
> On Mon, 15 Sep 2014 10:24:41 +0300, you wrote:
>
> >Hi,
> >
> >I think it should not be re-opened!
> >
> >1. JIRA is not support forum!
> >If you have questions then you should ask here (at users@ mailing list).
> >If you have ideas then you should discuss them at dev@ mailing list.
> >
> >2. If you want to not have the ?pageId in the url then you should stick to
> >stateless components and behaviors.
> >This is by design!
> >Stateful pages cannot work without the pageId parameter!
>
> What if Wicket switches processing in case of setVersion(false)? What
> would stop us from letting Wicket use a singleton page "version" if
> setVersion(false), making the version parameter entirely obsolete?
> This appears to be very logical to me. As I wrote in the Jira ticket,
> setVersioned(false) should just do what the word means. Currently that
> is not the case because we are saying Wicket needs the version number.
>
> >Solutions like NoVersionRequestMapper are pure hacks. Use them at your own
> >responsibility! Wicket developers are not responsible for them!
> >
>
> We want to change that. Honestly, this is the whole point. I am sick
> of these hacks that get broken because of what they are!
>
>
> >3. Wicket provides some default implementations for IRequestMapper
> >interface.
> >But it also allows you to provide your own when you believe the default
> >ones are not optimal for you.
> Same as above if I understand this right. I really don't feel strong
> enough about changing low level internals too much - risk of getting
> broken.
>
> >3.1. Wicket does its best to be backward compatible with previous
> versions.
> >Before every release we test the suggested new release with as much
> >applications as we have. If we find a regression we cancel the release and
> >cut a new one. You are very welcome to join us with testing your
> >application, with your custom implementations of Wicket interfaces, and
> >report regressions !
>
> Thanks for that. I am afraid of getting into some hacking mode where
> my custom implementation gets broken and I would just waste your time.
>
> >
> >
> >I'll copy my response to the ticket for cross reference.
> >
> >Martin Grigorov
> >Wicket Training and Consulting
> >https://twitter.com/mtgrigorov
> >
> >On Sun, Sep 14, 2014 at 10:55 AM, Bernard  wrote:
> >
> >> Hi,
> >>
> >> I created a Jira issue
> >>
> >> https://issues.apache.org/jira/browse/WICKET-5693
> >> setVersioned(false) should force single Page Version
> >>
> >> Initially information was not sufficient or clear enough so the issue
> >> was closed.
> >>
> >> Meanwhile I have added the requested information.
> >>
> >> Could this issue please be re-opened.
> >>
> >> Many thanks.
> >>
> >> Bernard
> >>
> >> ---
> >> This email is free from viruses and malware because avast! Antivirus
> >> protection is active.
> >> http://www.avast.com
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >>
>
>
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: turning off page versioning

[Martin Grigorov]

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 works with Class
instead of with Integer (pageId)
So everytime a url is mapped to a page class you should use it to load the
Page instance for this class

In details:
By design only stateless pages do not have the pageId in the url! If a
request without pageId comes then a completely new page instance is created.
By using something like NoVersionRequestMapper (not supported officially!)
only the url for the browser address bar will miss the pageId (see
PageAndComponentInfo class), but the pageId is in all link/form urls so
clicking/submitting still works. But if the user refreshes the page (F5)
then the state is lost!

About Page#setVersioned(boolean)
This tells Wicket to not increment the pageId after an interaction with the
page. A pageId is associated with the page when it is instantiated, but any
link click, form submit, etc. won't create a new version of the page. The
final result is that every interaction (i.e. state change) with the page
will lead to overriding the old one in the page stores.
Wicket's IPageStore/IDataStore use API like: put(String sessionId, int
pageId, byte[] serializedPage). At the end of every request cycle all
rendered stateful pages are stored. If the pageId doesn't change then some
old serializedPage would be overriden.

For your requirements you will need an API like: put(String sessionId,
Class pageClass, byte[] serializedPage) and byte [] get(String
sessionId, Class pageClass).
You can create a IPageManager wrapper that maps sessionId+pageId to
pageClass and use that pageClass with custom IMyPageStore and IMyDataStore
impls. (Just an idea out of my mind.)


Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Tue, Sep 23, 2014 at 3:42 AM, Garret Wilson 
wrote:

> 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 hit Button2,
> at which point the pages does Some Other Really Interesting Thing with the
> files. In other words, the page acts like a staging area for files,
> allowing you to 1) upload files and then 2) do something with them.
>
> I get this number on the end of the URLs which, from the page versioning
> and caching reference documentation  guide/guide/versioningCaching.html>, seems to indicate the version of the
> page. I don't want this. I just want there to be one version of the page
> (even though it is stateful). The back button can go to the previous page;
> I don't care.
>
> So I turn off versioning in StagingPage with:
>
>setVersioned(false);
>
>
> But I still get numbers at the end of the StagingPage URL. Worse, back and
> forward in my browser goes between apparently two versions of the page (one
> with the "Choose Files" button selecting files, and one without)---but the
> number in the URL doesn't change! Worse still, when I remove the number and
> reload the URL without the number, Wicket puts the number back but first
> increments the number! Now back and forward cycle between numbered URLs.
>
> I thought setVersioned(false) was supposed to turn all that off?
>
> In my own Guise framework, each page has a single component instance tree
> on the back end. Whatever you do at that URL, whenever you come back to it
> it will be just like you left it. Granted, there are several drawbacks such
> as memory consumption; Guise can learn a lot from Wicket in how the latter
> can serialize each page between requests, and versioning can be very useful
> in some situations. But here I just want a stateful page that has one
> single version---the current version. I don't want it to remember any
> previous versions. And I don't want numbers on the end of the URL. How can
> I turn off versioning for real?
>
> Thanks,
>
> Garret
>

Re: WiQuery for Wicket 6.17.0

[Rakesh A]

We are doing that, but wanted to get a confirmation .

Thank you,
Rakesh.A

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/WiQuery-for-Wicket-6-17-0-tp4667564p4667634.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: users-h...@wicket.apache.org