the url parameter is there only as a workaround for when we cannot set the header. i think the only usecase is for fileuploads where we have to set an ajax url on iframe's src attribute. the header is the preferred way to do this and you can set it yourself i you need or use wicket's ajax js to perform the request - which will set it for you.
-igor On Mon, Nov 1, 2010 at 11:59 PM, Frank van Lankvelt <[email protected]> wrote: > well, the two kinds of ajax requests differ; the WebRequest#isAjax method > returns true for wicket-ajax, but false for non-wicket-ajax requests. The > 'wicket-ajax' request has the Wicket-Ajax header, the other does not. So I > should have said that the first (locking) request was non-wicket-ajax; i.e. > an ajax request but without the Wicket-Ajax header set. > > Some further digging turned up the wicket:ajax request parameter; I guess I > should simply append it to the URL for the non-wicket-ajax behavior. > Perhaps that could happen in the base class AbstractAjaxBehavior? > > cheers, Frank > > On Tue, Nov 2, 2010 at 1:14 AM, Igor Vaynberg <[email protected]>wrote: > >> 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 >> <[email protected]> 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 <[email protected] >> >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 >> >> <[email protected]> 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 • [email protected] >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> > >> > >> > -- >> > 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 • [email protected] >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > 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 • [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
