You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Frank van Lankvelt <f....@onehippo.com> on 2010/11/01 17:14:57 UTC
wicket-ajax header from url?
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 • info@onehippo.com
Re: wicket-ajax header from url?
Posted by Frank van Lankvelt <f....@onehippo.com>.
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 <ig...@gmail.com>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
> <f....@onehippo.com> 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 <igor.vaynberg@gmail.com
> >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
> >> <f....@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.vaynberg@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....@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 • info@onehippo.com
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@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 • info@onehippo.com
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@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 • info@onehippo.com
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@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 • info@onehippo.com
Re: wicket-ajax header from url?
Posted by Igor Vaynberg <ig...@gmail.com>.
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
<f....@onehippo.com> 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 <ig...@gmail.com>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
>> <f....@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.vaynberg@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....@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 • info@onehippo.com
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@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 • info@onehippo.com
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@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 • info@onehippo.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-ajax header from url?
Posted by Frank van Lankvelt <f....@onehippo.com>.
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 <ig...@gmail.com>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
> <f....@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.vaynberg@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....@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 • info@onehippo.com
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@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 • info@onehippo.com
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@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 • info@onehippo.com
Re: wicket-ajax header from url?
Posted by Igor Vaynberg <ig...@gmail.com>.
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....@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 <ig...@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....@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 • info@onehippo.com
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@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 • info@onehippo.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-ajax header from url?
Posted by Frank van Lankvelt <f....@onehippo.com>.
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 <ig...@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....@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 • info@onehippo.com
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@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 • info@onehippo.com
Re: wicket-ajax header from url?
Posted by Igor Vaynberg <ig...@gmail.com>.
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....@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 • info@onehippo.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org