Is it possible that it occurs when a user stays on a bookmarkable page
for a long time (the page having forms) and then clicks trying to
submit the form after the session has expired? Could I just nest a
hidden form field that I could use to determine the page? What would
be the right place to process the hidden field in case of page
expiration? AbstractRequestCycleProcessor?
**
Martin
2009/1/16 Igor Vaynberg <igor.vaynb...@gmail.com>:
> bookmarkable urls do not generate a page expired error, the urls that
> do generally look like this:
>
> ?wicket:interface=2:ff.sdfsdf.sdf:ILinkListener
>
> where the only information you have about the page is "2".
>
> you can write your own coding strategy that always appends the class
> name of the last bookmarkable page to all the urls...that way you can
> recover it but it sure wont look pretty.
>
> -igor
>
> On Fri, Jan 16, 2009 at 12:09 PM, Martin Makundi
> <martin.maku...@koodaripalvelut.com> wrote:
>> Specifically, if it is a Mounted Bookmarkable page, the page name
>> should be available in the url?
>>
>> **
>> Martin
>>
>> 2009/1/16 Martin Makundi <martin.maku...@koodaripalvelut.com>:
>>>> when you hit pageexpired exception you do not know which page caused it
>>>
>>> Is it possible that there could be some query parameters that could be
>>> used to deduce such information?
>>>
>>> **
>>> Martin
>>>
>>>>
>>>> On Fri, Jan 16, 2009 at 11:18 AM, Martin Makundi
>>>> <martin.maku...@koodaripalvelut.com> wrote:
>>>>> Hi!
>>>>>
>>>>> I would like to ignore "page expired" on certain pages. What I mean is
>>>>> that in general it is ok to follow the instruction:
>>>>>
>>>>> getApplicationSettings().setPageExpiredErrorPage(LoginPage.class);
>>>>>
>>>>> However, on certain pages where the session is not so important, I
>>>>> would like to redirect back to the ongoing page (without
>>>>> RestartResponseException) because there is no harm (I can check some
>>>>> @SafeExpired annotation or something, to make sure).
>>>>>
>>>>> I found the following piece from AbstractRequestCycleProcessor:
>>>>> if (e instanceof PageExpiredException)
>>>>> {
>>>>> Class<? extends Page> pageExpiredErrorPageClass =
>>>>> application.getApplicationSettings()
>>>>> .getPageExpiredErrorPage();
>>>>> boolean mounted = isPageMounted(pageExpiredErrorPageClass);
>>>>> RequestCycle.get().setRedirect(mounted);
>>>>> throw new RestartResponseException(pageExpiredErrorPageClass);
>>>>> }
>>>>>
>>>>> I could extend WebRequestCycleProcessor and override the method public
>>>>> void respond(RuntimeException e, RequestCycle requestCycle); with the
>>>>> intention of Catching the RestartResponseException and analyzing
>>>>> whether the target page meets the special conditions. If it does meet,
>>>>> I consume the RestartResponseException...
>>>>>
>>>>> Will this do the trick properly? Is this a good approach? Anybody done
>>>>> this before?
>>>>>
>>>>> It feels a bit like hacking into the wicket bloodlines, if the
>>>>> internals change the hack might not work in the future. Is there a
>>>>> more proper way to do this or should there be a new feature in Wicket
>>>>> to support selecting which pages care about expiration (or maybe there
>>>>> already is?)? These pages in question have only some plain forms and
>>>>> do not require login. Now if such a page expires, it redirects to
>>>>> login, which is really not the purpose.
>>>>>
>>>>> **
>>>>> Martin
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
