You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by aditsu <ad...@yahoo.com> on 2008/10/17 13:11:03 UTC
Stateless AJAX links
Hi, I managed to hack wicket (1.4-m3) to do a kind of stateless ajax link.
I extended AbstractLink and implemented ILinkListener, and added a custom
stateless AjaxEventBehavior that creates a callback url using the
ILinkListener interface (in order to get a
BookmarkableListenerInterfaceRequestTarget).
In onLinkClicked, I create an AjaxRequestTarget and then call an abstract
handler.
This is already a nasty hack, however it doesn't work yet by itself.
BookmarkableListenerInterfaceRequestTarget.processEvents calls
getPage(requestCycle) if it can't find a page, and that method creates a new
page... but only if !requestCycle.isRedirect(). And isRedirect returns true
for ajax requests.
getPage is also final (why?) so I had to override processEvents to make it
work.
What does isRedirect mean anyway? And why is it true for all ajax requests?
After hacking that, the stateless ajax link worked, however when I tried to
add a stateful form to the page through it, it didn't work because the page
wasn't stored in the session. I had to use yet another hack - I called
getRequestCycle().urlFor(getPage()) because that seems to touch the page in
the session.
So everything seems to work now, however I don't like having to use these
hacks, and I wonder if I broke anything by using them (especially the page
creation on redirect). Is there any better way to do ajax stateless links?
Is wicket going to support that anytime soon?
Thanks
Adrian
--
View this message in context: http://www.nabble.com/Stateless-AJAX-links-tp20031309p20031309.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Stateless AJAX links
Posted by aditsu <ad...@yahoo.com>.
igor.vaynberg wrote:
>
> can you set a breakpoint and see where response.redirect is being called
> from for ajax processing? i can see it would be called if you added the
> page
> itself to the ajaxrequesttarget.
>
Actually, redirect seems to be false, but WebRequestCycle.isRedirect first
checks for isAjax. It also has a comment "If it's an ajax request we always
redirect."
I can try to debug it later to confirm, if needed.
igor.vaynberg wrote:
>
> as far as supporting stateless ajax goes, i am not sure if or when we are
> going to support it. we are not going to look into it until we start
> working
> on 1.5 (a month or two). the focus of wicket has never been stateless
> pages.
>
I understand; I was thinking that wicket already supports stateless pages,
and they can help improve the performance a lot, and from my experiment I
found that it's not really hard to make stateless ajax work.
Anyway, it's not bad if wicket will support that in a few months. Until
then, I wonder if my way of doing it is good.
Adrian
--
View this message in context: http://www.nabble.com/Stateless-AJAX-links-tp20031309p20082568.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Stateless AJAX links
Posted by Igor Vaynberg <ig...@gmail.com>.
can you set a breakpoint and see where response.redirect is being called
from for ajax processing? i can see it would be called if you added the page
itself to the ajaxrequesttarget.
as far as supporting stateless ajax goes, i am not sure if or when we are
going to support it. we are not going to look into it until we start working
on 1.5 (a month or two). the focus of wicket has never been stateless pages.
-igor
On Fri, Oct 17, 2008 at 4:11 AM, aditsu <ad...@yahoo.com> wrote:
>
> Hi, I managed to hack wicket (1.4-m3) to do a kind of stateless ajax link.
> I extended AbstractLink and implemented ILinkListener, and added a custom
> stateless AjaxEventBehavior that creates a callback url using the
> ILinkListener interface (in order to get a
> BookmarkableListenerInterfaceRequestTarget).
> In onLinkClicked, I create an AjaxRequestTarget and then call an abstract
> handler.
>
> This is already a nasty hack, however it doesn't work yet by itself.
> BookmarkableListenerInterfaceRequestTarget.processEvents calls
> getPage(requestCycle) if it can't find a page, and that method creates a
> new
> page... but only if !requestCycle.isRedirect(). And isRedirect returns true
> for ajax requests.
> getPage is also final (why?) so I had to override processEvents to make it
> work.
> What does isRedirect mean anyway? And why is it true for all ajax requests?
>
> After hacking that, the stateless ajax link worked, however when I tried to
> add a stateful form to the page through it, it didn't work because the page
> wasn't stored in the session. I had to use yet another hack - I called
> getRequestCycle().urlFor(getPage()) because that seems to touch the page in
> the session.
>
> So everything seems to work now, however I don't like having to use these
> hacks, and I wonder if I broke anything by using them (especially the page
> creation on redirect). Is there any better way to do ajax stateless links?
> Is wicket going to support that anytime soon?
>
> Thanks
> Adrian
> --
> View this message in context:
> http://www.nabble.com/Stateless-AJAX-links-tp20031309p20031309.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Stateless AJAX links
Posted by Erik van Oosten <e....@grons.nl>.
Adrian,
I can answer only these:
> - What is the meaning of redirect (in the context of RequestCycle)?
>
When the response target has the redirect flag set to true, Wicket will
issue a 302 Moved Temporarily response.
> - Why does BookmarkablePageRequestTarget.getPage(RequestCycle) only call
> newPage if isRedirect is false? And why is it final?
>
If it's true, a 302 redirect will be sent to the client, there is
therefore no need to create a page. That will be done when the
redirected request comes in.
Regards,
Erik.
aditsu wrote:
> Bump
> I still have several questions that haven't been answered:
> - What is the meaning of redirect (in the context of RequestCycle)?
> - Why does wicket always do redirect for ajax requests?
> - Why does BookmarkablePageRequestTarget.getPage(RequestCycle) only call
> newPage if isRedirect is false? And why is it final?
> - When I respond to the ajax request, adding a stateful component (therefore
> making the page stateful), why is the page not stored in the session
> automatically?
> - Are there any problems with the hacks I used? Do they break anything?
> - Is there any better way to do what I am trying to do?
>
> Thanks
> Adrian
>
>
>
--
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Stateless AJAX links
Posted by Johan Compagner <jc...@gmail.com>.
what doesnt work?
it will throw a page expire now and that works.
It should work now just as normal links.
On Sun, Oct 26, 2008 at 7:06 PM, aditsu <ad...@yahoo.com> wrote:
>
>
> aditsu wrote:
> >
> > Furthermore, BookmarkableListenerInterfaceRequestTarget.processEvents
> > simply assumes that the page is not null after calling
> > getPage(requestCycle)
> >
>
> Oops, correction. This has changed between 1.4-m2 and m3, now it checks and
> throws a PageExpiredException. Either way, it won't work.
>
> Adrian
> --
> View this message in context:
> http://www.nabble.com/Stateless-AJAX-links-tp20031309p20175686.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Stateless AJAX links
Posted by aditsu <ad...@yahoo.com>.
aditsu wrote:
>
> Furthermore, BookmarkableListenerInterfaceRequestTarget.processEvents
> simply assumes that the page is not null after calling
> getPage(requestCycle)
>
Oops, correction. This has changed between 1.4-m2 and m3, now it checks and
throws a PageExpiredException. Either way, it won't work.
Adrian
--
View this message in context: http://www.nabble.com/Stateless-AJAX-links-tp20031309p20175686.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Stateless AJAX links
Posted by Apple Grew <ap...@gmail.com>.
Joachim. Thanks a lot got your contribution.
Regards,
Apple Grew
my blog @ http://blog.applegrew.com/
On Sat, Jan 30, 2010 at 3:43 AM, Joachim Kainz <jf...@jolira.com> wrote:
>
> I have created a wiki page with my solution for stateless Ajax at
>
> http://cwiki.apache.org/confluence/display/WICKET/A+StatelessAjaxFallbackLink
> .
>
>
> jcompagner-2 wrote:
> >
> > we dont know that really if it is the respond step
> > And normally that getPage() isnt called in wicket when not in a Response
> > step
> >
> > what you do is currently not supported by wicket
> > having an ajax behavior request to a stateless page (through a
> > BookmarkableListenerInterfaceRequestTarget)
> > so i guess the fix is in processEvents is not doing this:
> >
> > else if (page == null)
> > {
> > page = getPage(requestCycle);
> > }
> >
> > but
> >
> > else if (page == null)
> > {
> > page = newPage(getPageClass(), requestCycle);
> > }
> >
> > johan
> >
> >
> >
> > On Mon, Oct 27, 2008 at 7:51 PM, aditsu <ad...@yahoo.com> wrote:
> >
> >>
> >> Hi, I thought about what you said, and debugged some more. Here's what I
> >> found out:
> >>
> >>
> >> Johan Compagner wrote:
> >> >
> >> > RequestCycle.isRedirect() is right, because that is a call that tells
> >> us
> >> > must i redirect of i get a page redirect
> >> > and with ajax this is always the case.
> >> >
> >> > Problem is that the BookmarkablePageRequestTarget.getPage(RC) should
> >> only
> >> > create a page when it is not a redirect
> >> > And that also correct.
> >> >
> >>
> >> Actually, neither BehaviorRequestTarget nor AjaxRequestTarget ever check
> >> for
> >> redirect. As long as the target is not changed to something else, the
> >> redirect setting is ignored.
> >> AFAICT, the redirect-for-ajax thing is there so that *if* the *final*
> >> request target is something other than AjaxRequestTarget, it will cause
> a
> >> redirect.
> >> E.g. if in my handler method I set the response page to a bookmarkable
> >> page,
> >> then it should do a redirect indeed (that is, a javascript redirect, not
> >> an
> >> http 302).
> >>
> >> The problem is that my initial target is
> >> BookmarkableListenerInterfaceRequestTarget, before changing to
> >> AjaxRequestTarget, and wicket doesn't expect that. It sees a non-ajax
> >> target
> >> for an ajax request, so it just blindly says "this is a redirect", when
> >> actually I'm not gonna do that.
> >>
> >> So I think isRedirect should NOT check for ajax unless it's at the
> >> RESPOND
> >> step. In the PROCESS_EVENTS step it should only check for the redirect
> >> flag.
> >> That would probably solve my problem and at the same time it would start
> >> to
> >> make sense. What do you think?
> >>
> >> Adrian
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Stateless-AJAX-links-tp20031309p20193967.html
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/Stateless-AJAX-links-tp20031309p27378984.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Stateless AJAX links
Posted by Joachim Kainz <jf...@jolira.com>.
I have created a wiki page with my solution for stateless Ajax at
http://cwiki.apache.org/confluence/display/WICKET/A+StatelessAjaxFallbackLink.
jcompagner-2 wrote:
>
> we dont know that really if it is the respond step
> And normally that getPage() isnt called in wicket when not in a Response
> step
>
> what you do is currently not supported by wicket
> having an ajax behavior request to a stateless page (through a
> BookmarkableListenerInterfaceRequestTarget)
> so i guess the fix is in processEvents is not doing this:
>
> else if (page == null)
> {
> page = getPage(requestCycle);
> }
>
> but
>
> else if (page == null)
> {
> page = newPage(getPageClass(), requestCycle);
> }
>
> johan
>
>
>
> On Mon, Oct 27, 2008 at 7:51 PM, aditsu <ad...@yahoo.com> wrote:
>
>>
>> Hi, I thought about what you said, and debugged some more. Here's what I
>> found out:
>>
>>
>> Johan Compagner wrote:
>> >
>> > RequestCycle.isRedirect() is right, because that is a call that tells
>> us
>> > must i redirect of i get a page redirect
>> > and with ajax this is always the case.
>> >
>> > Problem is that the BookmarkablePageRequestTarget.getPage(RC) should
>> only
>> > create a page when it is not a redirect
>> > And that also correct.
>> >
>>
>> Actually, neither BehaviorRequestTarget nor AjaxRequestTarget ever check
>> for
>> redirect. As long as the target is not changed to something else, the
>> redirect setting is ignored.
>> AFAICT, the redirect-for-ajax thing is there so that *if* the *final*
>> request target is something other than AjaxRequestTarget, it will cause a
>> redirect.
>> E.g. if in my handler method I set the response page to a bookmarkable
>> page,
>> then it should do a redirect indeed (that is, a javascript redirect, not
>> an
>> http 302).
>>
>> The problem is that my initial target is
>> BookmarkableListenerInterfaceRequestTarget, before changing to
>> AjaxRequestTarget, and wicket doesn't expect that. It sees a non-ajax
>> target
>> for an ajax request, so it just blindly says "this is a redirect", when
>> actually I'm not gonna do that.
>>
>> So I think isRedirect should NOT check for ajax unless it's at the
>> RESPOND
>> step. In the PROCESS_EVENTS step it should only check for the redirect
>> flag.
>> That would probably solve my problem and at the same time it would start
>> to
>> make sense. What do you think?
>>
>> Adrian
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Stateless-AJAX-links-tp20031309p20193967.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://old.nabble.com/Stateless-AJAX-links-tp20031309p27378984.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Stateless AJAX links
Posted by Johan Compagner <jc...@gmail.com>.
we dont know that really if it is the respond step
And normally that getPage() isnt called in wicket when not in a Response
step
what you do is currently not supported by wicket
having an ajax behavior request to a stateless page (through a
BookmarkableListenerInterfaceRequestTarget)
so i guess the fix is in processEvents is not doing this:
else if (page == null)
{
page = getPage(requestCycle);
}
but
else if (page == null)
{
page = newPage(getPageClass(), requestCycle);
}
johan
On Mon, Oct 27, 2008 at 7:51 PM, aditsu <ad...@yahoo.com> wrote:
>
> Hi, I thought about what you said, and debugged some more. Here's what I
> found out:
>
>
> Johan Compagner wrote:
> >
> > RequestCycle.isRedirect() is right, because that is a call that tells us
> > must i redirect of i get a page redirect
> > and with ajax this is always the case.
> >
> > Problem is that the BookmarkablePageRequestTarget.getPage(RC) should only
> > create a page when it is not a redirect
> > And that also correct.
> >
>
> Actually, neither BehaviorRequestTarget nor AjaxRequestTarget ever check
> for
> redirect. As long as the target is not changed to something else, the
> redirect setting is ignored.
> AFAICT, the redirect-for-ajax thing is there so that *if* the *final*
> request target is something other than AjaxRequestTarget, it will cause a
> redirect.
> E.g. if in my handler method I set the response page to a bookmarkable
> page,
> then it should do a redirect indeed (that is, a javascript redirect, not an
> http 302).
>
> The problem is that my initial target is
> BookmarkableListenerInterfaceRequestTarget, before changing to
> AjaxRequestTarget, and wicket doesn't expect that. It sees a non-ajax
> target
> for an ajax request, so it just blindly says "this is a redirect", when
> actually I'm not gonna do that.
>
> So I think isRedirect should NOT check for ajax unless it's at the RESPOND
> step. In the PROCESS_EVENTS step it should only check for the redirect
> flag.
> That would probably solve my problem and at the same time it would start to
> make sense. What do you think?
>
> Adrian
>
> --
> View this message in context:
> http://www.nabble.com/Stateless-AJAX-links-tp20031309p20193967.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Stateless AJAX links
Posted by aditsu <ad...@yahoo.com>.
Hi, I thought about what you said, and debugged some more. Here's what I
found out:
Johan Compagner wrote:
>
> RequestCycle.isRedirect() is right, because that is a call that tells us
> must i redirect of i get a page redirect
> and with ajax this is always the case.
>
> Problem is that the BookmarkablePageRequestTarget.getPage(RC) should only
> create a page when it is not a redirect
> And that also correct.
>
Actually, neither BehaviorRequestTarget nor AjaxRequestTarget ever check for
redirect. As long as the target is not changed to something else, the
redirect setting is ignored.
AFAICT, the redirect-for-ajax thing is there so that *if* the *final*
request target is something other than AjaxRequestTarget, it will cause a
redirect.
E.g. if in my handler method I set the response page to a bookmarkable page,
then it should do a redirect indeed (that is, a javascript redirect, not an
http 302).
The problem is that my initial target is
BookmarkableListenerInterfaceRequestTarget, before changing to
AjaxRequestTarget, and wicket doesn't expect that. It sees a non-ajax target
for an ajax request, so it just blindly says "this is a redirect", when
actually I'm not gonna do that.
So I think isRedirect should NOT check for ajax unless it's at the RESPOND
step. In the PROCESS_EVENTS step it should only check for the redirect flag.
That would probably solve my problem and at the same time it would start to
make sense. What do you think?
Adrian
--
View this message in context: http://www.nabble.com/Stateless-AJAX-links-tp20031309p20193967.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Stateless AJAX links
Posted by Johan Compagner <jc...@gmail.com>.
this is just all because you want stateless pages with ajax behaviors
which is currently just not supported
RequestCycle.isRedirect() is right, because that is a call that tells us
must i redirect of i get a page redirect
and with ajax this is always the case.
Problem is that the BookmarkablePageRequestTarget.getPage(RC) should only
create a page when it is not a redirect
And that also correct.
i guess what should happen is that
BookmarkableListenerInterfaceRequestTarget
should override that getPage(RC) method and depening on some state it should
create the page and not look at the redirect flag.
johan
On Mon, Oct 27, 2008 at 11:11 AM, aditsu <ad...@yahoo.com> wrote:
>
>
> Johan Compagner wrote:
> >
> > what doesnt work?
> > it will throw a page expire now and that works.
> > It should work now just as normal links.
> >
>
> *My page* doesn't work in that situation, since wicket thinks it's expired.
>
>
>
> >> It's an ajax request that makes changes to the current page (without
> >> going
> >> to another page). What does that have to do with redirecting?
> >
> > redirect is only relevant if you redirect to a page
> > If it is a "normal" ajax request that just renders some components then
> > redirect boolean is used at all.
> > Then you just have an AjaxRequestTarget that does its work.
> >
>
> Have you read my previous messages?
> BookmarkablePageRequestTarget.getPage(RequestCycle) checks for isRedirect
> before calling newPage.
> isRedirect ALWAYS returns true for ajax requests (WHY???)
> I had to override a method to workaround this problem.
>
>
>
> > So you are just rendering a few components then the rendering/response
> > phase
> > shouldnt touch the redirect at all see above
> > you just have a AjaxRequestTarget
> >
>
> No, the original request target is never an AjaxRequestTarget.
> Normally it's a BehaviorRequestTarget but I'm using a
> BookmarkableListenerInterfaceRequestTarget instead.
> Only after the initial processing (which in my case has the problems I
> mentioned above), the target is changed to an AjaxRequestTarget.
>
>
>
> > see above, AjaxRequestTarget should then handle the response and that one
> > doesnt look at the redirect
> > and the redirect boolean is only relevant for the Response not the
> > request.
> >
>
> See above, the target is not an AjaxRequestTarget yet, it is
> BookmarkableListenerInterfaceRequestTarget.
> And it looks at isRedirect(), which doesn't even look at the redirect
> boolean because it checks for isAjax first and returns true.
> Again, why does isRedirect() always return true for ajax requests?
>
>
>
> > then just use statefull pages
> > I dont get why you have partial updated pages, that are constantly
> created
> > as the original again because
> > you want stateless pages.
> > Dont you want to keep that partial updated page in memory?
> > I guess you dont have any callbacks in the things you update? that is
> just
> > text/images?
> >
>
> The initial pages are stateless because this way I can cache them and serve
> up to 6000 requests per second or more, instead of 0.5 to 25 requests per
> second.
> In over 95% of the cases, users won't click on the ajax link. No wicket
> code
> will be executed.
> For the few cases when they do click, only one page will be created per
> session (I had to trick wicket to put it in the session, that was one of
> the
> other problems I mentioned). The component I am adding through the ajax
> request is a stateful form. I wanted to make it stateless, but there
> doesn't
> seem to be any reasonable way to do that, because it includes a captcha
> field.
> Anyway, everything is working now, but I wanted some answers to those
> questions.
>
> Regards,
> Adrian
> --
> View this message in context:
> http://www.nabble.com/Stateless-AJAX-links-tp20031309p20184803.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Stateless AJAX links
Posted by aditsu <ad...@yahoo.com>.
John Patterson wrote:
>
>
> aditsu wrote:
>>
>> Anyway, everything is working now, but I wanted some answers to those
>> questions.
>>
>
> I am very interested in what you have achieved here. Is there any chance
> you could summarise what you had to do to get stateless AJAX links to
> work? Perhaps just a post to this topic or even a wiki page?
>
My first post in this thread pretty much describes what I did. You can find
it at http://www.nabble.com/Stateless-AJAX-links-td20031309.html
Feel free to ask for details where it's not clear.
Adrian
--
View this message in context: http://www.nabble.com/Stateless-AJAX-links-tp20031309p20189364.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Stateless AJAX links
Posted by John Patterson <jd...@gmail.com>.
aditsu wrote:
>
> Anyway, everything is working now, but I wanted some answers to those
> questions.
>
I am very interested in what you have achieved here. Is there any chance
you could summarise what you had to do to get stateless AJAX links to work?
Perhaps just a post to this topic or even a wiki page?
Thanks,
John
--
View this message in context: http://www.nabble.com/Stateless-AJAX-links-tp20031309p20187534.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Stateless AJAX links
Posted by aditsu <ad...@yahoo.com>.
Johan Compagner wrote:
>
> what doesnt work?
> it will throw a page expire now and that works.
> It should work now just as normal links.
>
*My page* doesn't work in that situation, since wicket thinks it's expired.
>> It's an ajax request that makes changes to the current page (without
>> going
>> to another page). What does that have to do with redirecting?
>
> redirect is only relevant if you redirect to a page
> If it is a "normal" ajax request that just renders some components then
> redirect boolean is used at all.
> Then you just have an AjaxRequestTarget that does its work.
>
Have you read my previous messages?
BookmarkablePageRequestTarget.getPage(RequestCycle) checks for isRedirect
before calling newPage.
isRedirect ALWAYS returns true for ajax requests (WHY???)
I had to override a method to workaround this problem.
> So you are just rendering a few components then the rendering/response
> phase
> shouldnt touch the redirect at all see above
> you just have a AjaxRequestTarget
>
No, the original request target is never an AjaxRequestTarget.
Normally it's a BehaviorRequestTarget but I'm using a
BookmarkableListenerInterfaceRequestTarget instead.
Only after the initial processing (which in my case has the problems I
mentioned above), the target is changed to an AjaxRequestTarget.
> see above, AjaxRequestTarget should then handle the response and that one
> doesnt look at the redirect
> and the redirect boolean is only relevant for the Response not the
> request.
>
See above, the target is not an AjaxRequestTarget yet, it is
BookmarkableListenerInterfaceRequestTarget.
And it looks at isRedirect(), which doesn't even look at the redirect
boolean because it checks for isAjax first and returns true.
Again, why does isRedirect() always return true for ajax requests?
> then just use statefull pages
> I dont get why you have partial updated pages, that are constantly created
> as the original again because
> you want stateless pages.
> Dont you want to keep that partial updated page in memory?
> I guess you dont have any callbacks in the things you update? that is just
> text/images?
>
The initial pages are stateless because this way I can cache them and serve
up to 6000 requests per second or more, instead of 0.5 to 25 requests per
second.
In over 95% of the cases, users won't click on the ajax link. No wicket code
will be executed.
For the few cases when they do click, only one page will be created per
session (I had to trick wicket to put it in the session, that was one of the
other problems I mentioned). The component I am adding through the ajax
request is a stateful form. I wanted to make it stateless, but there doesn't
seem to be any reasonable way to do that, because it includes a captcha
field.
Anyway, everything is working now, but I wanted some answers to those
questions.
Regards,
Adrian
--
View this message in context: http://www.nabble.com/Stateless-AJAX-links-tp20031309p20184803.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Stateless AJAX links
Posted by Johan Compagner <jc...@gmail.com>.
> > Because how else would you render the resulting page?
> >
>
> It's an ajax request that makes changes to the current page (without going
> to another page). What does that have to do with redirecting?
>
redirect is only relevant if you redirect to a page
If it is a "normal" ajax request that just renders some components then
redirect boolean is used at all.
Then you just have an AjaxRequestTarget that does its work.
>
>
>
> > Do you really want to replace the complete dom with a new page without
> the
> > browser doing a normal get?
> > Then the url thats in the browser wouldnt point at all anymore to the
> > right
> > page (if a user would do refresh in a browser)
> >
>
> No, I just replace part of the dom of the current page.
> If the user refreshes the page, he/she will see the original page again
> (like it was before the changes).
So you are just rendering a few components then the rendering/response phase
shouldnt touch the redirect at all see above
you just have a AjaxRequestTarget
Maybe because the request phase is different for you because you try to have
an stateless page and that is something that
wicket doesnt support for ajax.
>
>
> > if you click an ajax link and you want to show a different page then yes
> a
> > redirect to that page has to happen
> > else we have to replace the complete document with the new page, dont
> know
> > if we really support that and if that will go fine in all the browsers.
> >
>
> Yeah, *if* I want to show a different page. (By the way, a 302 redirect
> won't help in that case, but I see that it automatically uses another way
> for ajax requests).
> However I *don't* want to show a different page.
see above, AjaxRequestTarget should then handle the response and that one
doesnt look at the redirect
and the redirect boolean is only relevant for the Response not the request.
>
>
>
>
> >> - Is there any better way to do what I am trying to do?
> >
> > yes why have ajax links that could be just normal links if you want to
> > have
> > a stateless page.
> >
>
> That could work, but I'd rather not render and send the whole updated page
> to the browser, when most of it doesn't change. How would that be better?
then just use statefull pages
I dont get why you have partial updated pages, that are constantly created
as the original again because
you want stateless pages.
Dont you want to keep that partial updated page in memory?
I guess you dont have any callbacks in the things you update? that is just
text/images?
Re: Stateless AJAX links
Posted by aditsu <ad...@yahoo.com>.
Thanks. but some of the things don't really make sense:
Johan Compagner wrote:
>
>> - Why does wicket always do redirect for ajax requests?
>
> Because how else would you render the resulting page?
>
It's an ajax request that makes changes to the current page (without going
to another page). What does that have to do with redirecting?
> Do you really want to replace the complete dom with a new page without the
> browser doing a normal get?
> Then the url thats in the browser wouldnt point at all anymore to the
> right
> page (if a user would do refresh in a browser)
>
No, I just replace part of the dom of the current page.
If the user refreshes the page, he/she will see the original page again
(like it was before the changes).
>> - Why does BookmarkablePageRequestTarget.getPage(RequestCycle) only call
>> newPage if isRedirect is false? And why is it final?
>
> see eriks reply, again the redirect is done through the browser as a
> second
> request
> else the url in the browser doesnt point to the right page.
>
Well, then how can it possibly know what to redirect to, if it has no page?
Furthermore, BookmarkableListenerInterfaceRequestTarget.processEvents simply
assumes that the page is not null after calling getPage(requestCycle)
> if you click an ajax link and you want to show a different page then yes a
> redirect to that page has to happen
> else we have to replace the complete document with the new page, dont know
> if we really support that and if that will go fine in all the browsers.
>
Yeah, *if* I want to show a different page. (By the way, a 302 redirect
won't help in that case, but I see that it automatically uses another way
for ajax requests).
However I *don't* want to show a different page.
>> - Is there any better way to do what I am trying to do?
>
> yes why have ajax links that could be just normal links if you want to
> have
> a stateless page.
>
That could work, but I'd rather not render and send the whole updated page
to the browser, when most of it doesn't change. How would that be better?
Adrian
--
View this message in context: http://www.nabble.com/Stateless-AJAX-links-tp20031309p20175375.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Stateless AJAX links
Posted by Johan Compagner <jc...@gmail.com>.
> I still have several questions that haven't been answered:
> - What is the meaning of redirect (in the context of RequestCycle)?
See eriks reply, you redirect through the browser to that page so that the
url in the bar is really pointing to that page.
>
> - Why does wicket always do redirect for ajax requests?
Because how else would you render the resulting page?
Do you really want to replace the complete dom with a new page without the
browser doing a normal get?
Then the url thats in the browser wouldnt point at all anymore to the right
page (if a user would do refresh in a browser)
> - Why does BookmarkablePageRequestTarget.getPage(RequestCycle) only call
> newPage if isRedirect is false? And why is it final?
see eriks reply, again the redirect is done through the browser as a second
request
else the url in the browser doesnt point to the right page.
>
> - When I respond to the ajax request, adding a stateful component
> (therefore
> making the page stateful), why is the page not stored in the session
> automatically?
it should all statefull pages are stored in the session.
if you have a case where that doesnt happen please make a jira issue.
>
> - Are there any problems with the hacks I used? Do they break anything?
dont know exactly.
if you click an ajax link and you want to show a different page then yes a
redirect to that page has to happen
else we have to replace the complete document with the new page, dont know
if we really support that and if that will go fine in all the browsers.
>
> - Is there any better way to do what I am trying to do?
yes why have ajax links that could be just normal links if you want to have
a stateless page.
johan
Re: Stateless AJAX links
Posted by aditsu <ad...@yahoo.com>.
Bump
I still have several questions that haven't been answered:
- What is the meaning of redirect (in the context of RequestCycle)?
- Why does wicket always do redirect for ajax requests?
- Why does BookmarkablePageRequestTarget.getPage(RequestCycle) only call
newPage if isRedirect is false? And why is it final?
- When I respond to the ajax request, adding a stateful component (therefore
making the page stateful), why is the page not stored in the session
automatically?
- Are there any problems with the hacks I used? Do they break anything?
- Is there any better way to do what I am trying to do?
Thanks
Adrian
aditsu wrote:
>
> Hi, I managed to hack wicket (1.4-m3) to do a kind of stateless ajax link.
> I extended AbstractLink and implemented ILinkListener, and added a custom
> stateless AjaxEventBehavior that creates a callback url using the
> ILinkListener interface (in order to get a
> BookmarkableListenerInterfaceRequestTarget).
> In onLinkClicked, I create an AjaxRequestTarget and then call an abstract
> handler.
>
> This is already a nasty hack, however it doesn't work yet by itself.
> BookmarkableListenerInterfaceRequestTarget.processEvents calls
> getPage(requestCycle) if it can't find a page, and that method creates a
> new page... but only if !requestCycle.isRedirect(). And isRedirect returns
> true for ajax requests.
> getPage is also final (why?) so I had to override processEvents to make it
> work.
> What does isRedirect mean anyway? And why is it true for all ajax
> requests?
>
> After hacking that, the stateless ajax link worked, however when I tried
> to add a stateful form to the page through it, it didn't work because the
> page wasn't stored in the session. I had to use yet another hack - I
> called getRequestCycle().urlFor(getPage()) because that seems to touch the
> page in the session.
>
> So everything seems to work now, however I don't like having to use these
> hacks, and I wonder if I broke anything by using them (especially the page
> creation on redirect). Is there any better way to do ajax stateless links?
> Is wicket going to support that anytime soon?
>
> Thanks
> Adrian
>
--
View this message in context: http://www.nabble.com/Stateless-AJAX-links-tp20031309p20166433.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org