I think it would make sense to have any requests targeting an abstract-ajax-behavior be marked as 'ajax', without requiring client-side logic. This makes client-side integration quite straightforward. One then only needs to implement the server side of the protocol, without having to intercept the request creation process. It also makes request handling more robust in the face of concurrent requests, as I experienced.
Implementing this behavior with the wicket:ajax parameter in the url does require support when rendering urls; should be easy in 1.5, is currently not possible in 1.4 since the webrequestcodingstrategy does not render user-defined request parameters. I'm now doing it by simply appending '&wicket:ajax=true' in the getCallbackUrl method. There are probably alternative solutions that do not require a parameter in the url; I haven't looked into those yet. thanks for clarifying, Frank On Tue, Nov 2, 2010 at 7:03 PM, Igor Vaynberg <[email protected]>wrote: > 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] > > -- 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]
