so why is there the non-ajax request? once the page is loaded everything else - communication with ext - should be happening via ajax requests...
-igor On Mon, Nov 1, 2010 at 1:20 PM, Frank van Lankvelt <f.vanlankv...@onehippo.com> wrote: > it returned false because > a) the locking request was not ajax > b) the current request was ajax > c) they shared the same page version > Page versioning is disabled, though that shouldn't matter. (that might be a > worthwhile additional check before comparing versions; I'm not very familiar > with versions) > > It's a concurrency issue for one page, with some non-wicket-ajax behaviors, > so it might be pushing what people have seen? > > Both ext-js integration projects I've found have the same basic setup; use > AbstractAjaxBehavior to provide data services, use > AbstractDefaultAjaxBehavior subclasses for listening to Ext events. So > that's also where my bug occurs; I'm switching between ext components on the > client as the result of some action. The action leads to a notification to > wicket, the new component starts fetching data. > > thanks, Frank > > On Mon, Nov 1, 2010 at 5:28 PM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote: > >> did you check why it returns false? ajax requests should not increment >> the page version, so they should always be "current". people have >> built extjs integrations before, you may look into one of those for >> hints. >> >> -igor >> >> On Mon, Nov 1, 2010 at 9:14 AM, Frank van Lankvelt >> <f.vanlankv...@onehippo.com> wrote: >> > In my attempts to integrate a javascript client-side framework (ext-js) >> to >> > wicket, I'm running into the problem that the client-side framework >> expects >> > URLs to send requests to, expecting a JSON/XML response. This is of >> course >> > perfectly natural behavior for a js framework. >> > >> > The documentation I could find suggested to use an AbstractAjaxBehavior. >> > However, this doesn't quite work. Concurrent proper wicket-ajax >> requests >> > (abstractdefaultajaxbehavior) are aborted due to >> > WebSession#isCurrentRequestValid returning false. >> > >> > Am I doing something wrong here, or should I simply override the >> > isCurrentRequestValid method to always return true? >> > >> > thanks, Frank >> > >> > PS: I'm using wicket-1.4.9; but couldn't find relevant issues that have >> been >> > fixed since this release >> > >> > -- >> > Hippo >> > Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 >> 522 >> > 4466 >> > USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 • >> +1 >> > (707) 773 4646 >> > Canada • Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T >> > 1S5 • +1 (514) 316 8966 >> > www.onehippo.com • www.onehippo.org • i...@onehippo.com >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > -- > Hippo > Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 > 4466 > USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 • +1 > (707) 773 4646 > Canada • Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T > 1S5 • +1 (514) 316 8966 > www.onehippo.com • www.onehippo.org • i...@onehippo.com > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
