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 <[EMAIL PROTECTED]> 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 < > [EMAIL PROTECTED]> 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 >> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
