You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by francisco treacy <fr...@gmail.com> on 2008/10/06 21:07:04 UTC
force page reload
hi,
i'm integrating a wicket application with an online payment system
provided by a bank.
i have a wicket stateful page (ie shows visa / mastercard icons) which
links to the bank app's payment page. depending on the transaction,
the bank sends us back a result code in an encrypted http url
parameter, appended to the url of our wicket page.
String encrypted =
getWebRequestCycle().getWebRequest().getHttpServletRequest().getParameter("DATA");
according to the bank's response, i decide whether to show a "please
pay" or a "thank you" page with wicket variations.
the only problem i am having here is: the wicket page is cached, so no
matter what the result is, it will show the last seen version in the
pagemap - that is, it won't re-execute the page's java code.
i tried overriding headers
protected void setHeaders(WebResponse response) {
response.setHeader("Pragma", "no-cache");
response.setDateHeader("Expires",0);
response.setHeader("Cache-Control", "no-cache, max-age=0,
must-revalidate, no-store");
}
but none of these http headers are seen in the html output whatsoever.
i also tried implementing IMarkupCacheKeyProvider and returning null.
with no success so far.
what should i do to execute the page's code, no matter when it is called?
thanks,
francisco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: force page reload
Posted by francisco treacy <fr...@gmail.com>.
yes... "the page must be bookmarkable" - so i need it anyway.
another question that pops out with your suggestion: when called, are
bookmarkable pages always instantiated? under any circumstance?
just to make sure that calling
http://localhost:8080/myapp/bookmarkable will always trigger the code.
sorry if this is obvious, i just never paid attention :)
francisco
On Tue, Oct 7, 2008 at 2:07 PM, Ryan Gravener <ry...@ryangravener.com> wrote:
> Just throwing this out there:
>
> http://wicketstuff.org/wicket13doc/org/apache/wicket/Page.html#setStatelessHint(boolean)
>
> Perhaps that may work.
>
>
> Ryan Gravener
> http://twitter.com/ryangravener
>
>
> On Tue, Oct 7, 2008 at 12:02 PM, francisco treacy <
> francisco.treacy@gmail.com> wrote:
>
>> as it is kind of a workflow and i had all the pages already prepared
>> by passing imodels along into constructors, i didn't want to have a
>> bookmarkablepage (whatever you pick: panels/pages/variations, you need
>> this one to "call the page executing the code"). but this was the
>> simpler solution, pass an id to the non wicket server through http
>> post, get it back and initialize the a detachablemodel again with the
>> id and the dao.
>>
>> so i changed a bit my code to fit this no-arg constructor page, which
>> is responsible of checking the http post params.
>>
>> imo it is a good idea to use variations. a panel could have also been,
>> of course, but i wanted to avoid boilerplate for just a "thank you". i
>> finally redirected to the next page. in any case, this is such a small
>> case that the approach is not so important here.
>>
>> thanks all!
>>
>> francisco
>>
>> On Tue, Oct 7, 2008 at 1:36 AM, Jeremy Thomerson
>> <je...@wickettraining.com> wrote:
>> > I'd wholeheartedly agree with the panel solution. Either one would work,
>> > but I think the panel is really good.
>> >
>> >
>> >
>> > --
>> > Jeremy Thomerson
>> > http://www.wickettraining.com
>> >
>> > On Mon, Oct 6, 2008 at 9:53 PM, John Krasnay <jo...@krasnay.ca> wrote:
>> >
>> >> On Mon, Oct 06, 2008 at 07:36:03PM -0200, francisco treacy wrote:
>> >> > thanks for your help, serkan.
>> >> >
>> >> > cool, this works. as a workaround nevertheless:
>> >> >
>> >> > -i wouldn't want my app to check every single request the existence of
>> >> > a parameter which i am going to use in only *one* page anyway
>> >> > -what if i have this param passed to another page that doesn't expect
>> >> > it? this could easily introduce new bugs
>> >> >
>> >> > isn't there another easy way to force reloading / not "caching" a
>> >> > page? why isn't setHeaders having any effect? should be
>> >> > straightforward - what am i missing here?
>> >> >
>> >> > thanks again anyone for some pointers!
>> >> >
>> >> > francisco
>> >> >
>> >>
>> >> It seems to me a bit strange to use markup variant for this. You could
>> >> have your callback page forward to the correct page like this:
>> >>
>> >> public CallbackPage(PageParameters params) {
>> >> if (params.getString("DATA").equals("good)) {
>> >> setResponsePage(PaymentGoodPage.class);
>> >> } else {
>> >> setResponsePage(TryAgainPage.class);
>> >> }
>> >> }
>> >>
>> >> Alternatively, you could instantiate an appropriate panel in your page:
>> >>
>> >> public CallbackPage(PageParameters params) {
>> >> if (params.getString("DATA").equals("good)) {
>> >> add(new PaymentGoodPanel("responsePanel"));
>> >> } else {
>> >> add(new TryAgainPanel("responsePanel"));
>> >> }
>> >> }
>> >>
>> >>
>> >> jk
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: force page reload
Posted by Ryan Gravener <ry...@ryangravener.com>.
Just throwing this out there:
http://wicketstuff.org/wicket13doc/org/apache/wicket/Page.html#setStatelessHint(boolean)
Perhaps that may work.
Ryan Gravener
http://twitter.com/ryangravener
On Tue, Oct 7, 2008 at 12:02 PM, francisco treacy <
francisco.treacy@gmail.com> wrote:
> as it is kind of a workflow and i had all the pages already prepared
> by passing imodels along into constructors, i didn't want to have a
> bookmarkablepage (whatever you pick: panels/pages/variations, you need
> this one to "call the page executing the code"). but this was the
> simpler solution, pass an id to the non wicket server through http
> post, get it back and initialize the a detachablemodel again with the
> id and the dao.
>
> so i changed a bit my code to fit this no-arg constructor page, which
> is responsible of checking the http post params.
>
> imo it is a good idea to use variations. a panel could have also been,
> of course, but i wanted to avoid boilerplate for just a "thank you". i
> finally redirected to the next page. in any case, this is such a small
> case that the approach is not so important here.
>
> thanks all!
>
> francisco
>
> On Tue, Oct 7, 2008 at 1:36 AM, Jeremy Thomerson
> <je...@wickettraining.com> wrote:
> > I'd wholeheartedly agree with the panel solution. Either one would work,
> > but I think the panel is really good.
> >
> >
> >
> > --
> > Jeremy Thomerson
> > http://www.wickettraining.com
> >
> > On Mon, Oct 6, 2008 at 9:53 PM, John Krasnay <jo...@krasnay.ca> wrote:
> >
> >> On Mon, Oct 06, 2008 at 07:36:03PM -0200, francisco treacy wrote:
> >> > thanks for your help, serkan.
> >> >
> >> > cool, this works. as a workaround nevertheless:
> >> >
> >> > -i wouldn't want my app to check every single request the existence of
> >> > a parameter which i am going to use in only *one* page anyway
> >> > -what if i have this param passed to another page that doesn't expect
> >> > it? this could easily introduce new bugs
> >> >
> >> > isn't there another easy way to force reloading / not "caching" a
> >> > page? why isn't setHeaders having any effect? should be
> >> > straightforward - what am i missing here?
> >> >
> >> > thanks again anyone for some pointers!
> >> >
> >> > francisco
> >> >
> >>
> >> It seems to me a bit strange to use markup variant for this. You could
> >> have your callback page forward to the correct page like this:
> >>
> >> public CallbackPage(PageParameters params) {
> >> if (params.getString("DATA").equals("good)) {
> >> setResponsePage(PaymentGoodPage.class);
> >> } else {
> >> setResponsePage(TryAgainPage.class);
> >> }
> >> }
> >>
> >> Alternatively, you could instantiate an appropriate panel in your page:
> >>
> >> public CallbackPage(PageParameters params) {
> >> if (params.getString("DATA").equals("good)) {
> >> add(new PaymentGoodPanel("responsePanel"));
> >> } else {
> >> add(new TryAgainPanel("responsePanel"));
> >> }
> >> }
> >>
> >>
> >> jk
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: force page reload
Posted by francisco treacy <fr...@gmail.com>.
as it is kind of a workflow and i had all the pages already prepared
by passing imodels along into constructors, i didn't want to have a
bookmarkablepage (whatever you pick: panels/pages/variations, you need
this one to "call the page executing the code"). but this was the
simpler solution, pass an id to the non wicket server through http
post, get it back and initialize the a detachablemodel again with the
id and the dao.
so i changed a bit my code to fit this no-arg constructor page, which
is responsible of checking the http post params.
imo it is a good idea to use variations. a panel could have also been,
of course, but i wanted to avoid boilerplate for just a "thank you". i
finally redirected to the next page. in any case, this is such a small
case that the approach is not so important here.
thanks all!
francisco
On Tue, Oct 7, 2008 at 1:36 AM, Jeremy Thomerson
<je...@wickettraining.com> wrote:
> I'd wholeheartedly agree with the panel solution. Either one would work,
> but I think the panel is really good.
>
>
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
> On Mon, Oct 6, 2008 at 9:53 PM, John Krasnay <jo...@krasnay.ca> wrote:
>
>> On Mon, Oct 06, 2008 at 07:36:03PM -0200, francisco treacy wrote:
>> > thanks for your help, serkan.
>> >
>> > cool, this works. as a workaround nevertheless:
>> >
>> > -i wouldn't want my app to check every single request the existence of
>> > a parameter which i am going to use in only *one* page anyway
>> > -what if i have this param passed to another page that doesn't expect
>> > it? this could easily introduce new bugs
>> >
>> > isn't there another easy way to force reloading / not "caching" a
>> > page? why isn't setHeaders having any effect? should be
>> > straightforward - what am i missing here?
>> >
>> > thanks again anyone for some pointers!
>> >
>> > francisco
>> >
>>
>> It seems to me a bit strange to use markup variant for this. You could
>> have your callback page forward to the correct page like this:
>>
>> public CallbackPage(PageParameters params) {
>> if (params.getString("DATA").equals("good)) {
>> setResponsePage(PaymentGoodPage.class);
>> } else {
>> setResponsePage(TryAgainPage.class);
>> }
>> }
>>
>> Alternatively, you could instantiate an appropriate panel in your page:
>>
>> public CallbackPage(PageParameters params) {
>> if (params.getString("DATA").equals("good)) {
>> add(new PaymentGoodPanel("responsePanel"));
>> } else {
>> add(new TryAgainPanel("responsePanel"));
>> }
>> }
>>
>>
>> jk
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: force page reload
Posted by Jeremy Thomerson <je...@wickettraining.com>.
I'd wholeheartedly agree with the panel solution. Either one would work,
but I think the panel is really good.
--
Jeremy Thomerson
http://www.wickettraining.com
On Mon, Oct 6, 2008 at 9:53 PM, John Krasnay <jo...@krasnay.ca> wrote:
> On Mon, Oct 06, 2008 at 07:36:03PM -0200, francisco treacy wrote:
> > thanks for your help, serkan.
> >
> > cool, this works. as a workaround nevertheless:
> >
> > -i wouldn't want my app to check every single request the existence of
> > a parameter which i am going to use in only *one* page anyway
> > -what if i have this param passed to another page that doesn't expect
> > it? this could easily introduce new bugs
> >
> > isn't there another easy way to force reloading / not "caching" a
> > page? why isn't setHeaders having any effect? should be
> > straightforward - what am i missing here?
> >
> > thanks again anyone for some pointers!
> >
> > francisco
> >
>
> It seems to me a bit strange to use markup variant for this. You could
> have your callback page forward to the correct page like this:
>
> public CallbackPage(PageParameters params) {
> if (params.getString("DATA").equals("good)) {
> setResponsePage(PaymentGoodPage.class);
> } else {
> setResponsePage(TryAgainPage.class);
> }
> }
>
> Alternatively, you could instantiate an appropriate panel in your page:
>
> public CallbackPage(PageParameters params) {
> if (params.getString("DATA").equals("good)) {
> add(new PaymentGoodPanel("responsePanel"));
> } else {
> add(new TryAgainPanel("responsePanel"));
> }
> }
>
>
> jk
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: force page reload
Posted by John Krasnay <jo...@krasnay.ca>.
On Mon, Oct 06, 2008 at 07:36:03PM -0200, francisco treacy wrote:
> thanks for your help, serkan.
>
> cool, this works. as a workaround nevertheless:
>
> -i wouldn't want my app to check every single request the existence of
> a parameter which i am going to use in only *one* page anyway
> -what if i have this param passed to another page that doesn't expect
> it? this could easily introduce new bugs
>
> isn't there another easy way to force reloading / not "caching" a
> page? why isn't setHeaders having any effect? should be
> straightforward - what am i missing here?
>
> thanks again anyone for some pointers!
>
> francisco
>
It seems to me a bit strange to use markup variant for this. You could
have your callback page forward to the correct page like this:
public CallbackPage(PageParameters params) {
if (params.getString("DATA").equals("good)) {
setResponsePage(PaymentGoodPage.class);
} else {
setResponsePage(TryAgainPage.class);
}
}
Alternatively, you could instantiate an appropriate panel in your page:
public CallbackPage(PageParameters params) {
if (params.getString("DATA").equals("good)) {
add(new PaymentGoodPanel("responsePanel"));
} else {
add(new TryAgainPanel("responsePanel"));
}
}
jk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: force page reload
Posted by francisco treacy <fr...@gmail.com>.
thanks for your help, serkan.
cool, this works. as a workaround nevertheless:
-i wouldn't want my app to check every single request the existence of
a parameter which i am going to use in only *one* page anyway
-what if i have this param passed to another page that doesn't expect
it? this could easily introduce new bugs
isn't there another easy way to force reloading / not "caching" a
page? why isn't setHeaders having any effect? should be
straightforward - what am i missing here?
thanks again anyone for some pointers!
francisco
On Mon, Oct 6, 2008 at 5:58 PM, Serkan Camurcuoglu
<Se...@telenity.com> wrote:
> If I understood you correctly, I've done something like this to show a different page depending on a url parameter. You should override the newRequestCycleProcessor() method of your application class, and return a different request target from the resolve method. Here I return a bookmarkablepagerequesttarget which creates a new home page if a certain parameter exists in the request:
>
> @Override
> protected IRequestCycleProcessor newRequestCycleProcessor() {
> return new WebRequestCycleProcessor() {
> @Override
> public IRequestTarget resolve(RequestCycle cycle, RequestParameters params) {
> if (null != params.getParameters().get(ContentSearchPage.PARAM_SEARCH_KEY)) {
> return new BookmarkablePageRequestTarget(ContentSearchPage.class);
> }
> return super.resolve(cycle, params);
> }
> };
> }
>
>
>
> -----Original Message-----
> From: francisco treacy [mailto:francisco.treacy@gmail.com]
> Sent: Mon 10/6/2008 10:07 PM
> To: users@wicket.apache.org
> Subject: force page reload
>
> hi,
>
> i'm integrating a wicket application with an online payment system
> provided by a bank.
>
> i have a wicket stateful page (ie shows visa / mastercard icons) which
> links to the bank app's payment page. depending on the transaction,
> the bank sends us back a result code in an encrypted http url
> parameter, appended to the url of our wicket page.
>
> String encrypted =
> getWebRequestCycle().getWebRequest().getHttpServletRequest().getParameter("DATA");
>
> according to the bank's response, i decide whether to show a "please
> pay" or a "thank you" page with wicket variations.
>
> the only problem i am having here is: the wicket page is cached, so no
> matter what the result is, it will show the last seen version in the
> pagemap - that is, it won't re-execute the page's java code.
>
> i tried overriding headers
>
> protected void setHeaders(WebResponse response) {
> response.setHeader("Pragma", "no-cache");
> response.setDateHeader("Expires",0);
> response.setHeader("Cache-Control", "no-cache, max-age=0,
> must-revalidate, no-store");
> }
>
> but none of these http headers are seen in the html output whatsoever.
>
> i also tried implementing IMarkupCacheKeyProvider and returning null.
> with no success so far.
>
> what should i do to execute the page's code, no matter when it is called?
>
> thanks,
>
> francisco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: force page reload
Posted by Serkan Camurcuoglu <Se...@telenity.com>.
If I understood you correctly, I've done something like this to show a different page depending on a url parameter. You should override the newRequestCycleProcessor() method of your application class, and return a different request target from the resolve method. Here I return a bookmarkablepagerequesttarget which creates a new home page if a certain parameter exists in the request:
@Override
protected IRequestCycleProcessor newRequestCycleProcessor() {
return new WebRequestCycleProcessor() {
@Override
public IRequestTarget resolve(RequestCycle cycle, RequestParameters params) {
if (null != params.getParameters().get(ContentSearchPage.PARAM_SEARCH_KEY)) {
return new BookmarkablePageRequestTarget(ContentSearchPage.class);
}
return super.resolve(cycle, params);
}
};
}
-----Original Message-----
From: francisco treacy [mailto:francisco.treacy@gmail.com]
Sent: Mon 10/6/2008 10:07 PM
To: users@wicket.apache.org
Subject: force page reload
hi,
i'm integrating a wicket application with an online payment system
provided by a bank.
i have a wicket stateful page (ie shows visa / mastercard icons) which
links to the bank app's payment page. depending on the transaction,
the bank sends us back a result code in an encrypted http url
parameter, appended to the url of our wicket page.
String encrypted =
getWebRequestCycle().getWebRequest().getHttpServletRequest().getParameter("DATA");
according to the bank's response, i decide whether to show a "please
pay" or a "thank you" page with wicket variations.
the only problem i am having here is: the wicket page is cached, so no
matter what the result is, it will show the last seen version in the
pagemap - that is, it won't re-execute the page's java code.
i tried overriding headers
protected void setHeaders(WebResponse response) {
response.setHeader("Pragma", "no-cache");
response.setDateHeader("Expires",0);
response.setHeader("Cache-Control", "no-cache, max-age=0,
must-revalidate, no-store");
}
but none of these http headers are seen in the html output whatsoever.
i also tried implementing IMarkupCacheKeyProvider and returning null.
with no success so far.
what should i do to execute the page's code, no matter when it is called?
thanks,
francisco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org