wicketstuff-push: centralizing requests
Hi, I'm currently using wicketstuff-push to push events to a page and it works pretty well, but not well enough. Before trying to move to a comet based implementation, I would like to improve the timer based implementation. In the current implementation you got as many AjaxTimer as you install the push on components on the same page. So if you have three components requiring push, you will have three requests each x seconds, to poll for push events from the three components. This would be much more efficient if I had only one request polling for all push events sent by all components on the page... Hence my first thought was to add the timer behavior to the page instead of the component, and verify that the same kind of behavior is not already installed before installing a new one. The problem is that when I install the behavior the component doesn't know its page. So I have to do something at this time, and then later when I know the page make sure that only one behavior is actually rendered. I see two solutions to this problem: - Add one timer behavior to each component (as today), and then when rendering the component use the wasRendered/markRendered methods of IHeaderResponse to render only one of them (using the isEnabled method to disable it if another similar one has already been rendered). But then I will have to update all the non rendered behaviors so that push events sent to them are actually sent to the only behavior which is rendered. - Modify the API of the push service and ask to enable push on a page before actually using push on components on the page. This would actually install a unique timer behavior on the page. Then when installing push on a component I could simply add something which could be located by the unique timer on the page to collect all push events (maybe a disabled behavior) Now that I expose the two options I think I prefer the first one. But I would like to gather feedback from experienced wicket developers to see if I'm not missing something or if you have better ideas about how to implement what I want. Thanks, Xavier -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://incubator.apache.org/ivy/ http://www.xoocode.org/
Re: wicketstuff-push: centralizing requests
Xavier Hanin wrote: Hi, I'm currently using wicketstuff-push to push events to a page and it works pretty well, but not well enough. Before trying to move to a comet based implementation, I would like to improve the timer based implementation. In the current implementation you got as many AjaxTimer as you install the push on components on the same page. So if you have three components requiring push, you will have three requests each x seconds, to poll for push events from the three components. This would be much more efficient if I had only one request polling for all push events sent by all components on the page... Hence my first thought was to add the timer behavior to the page instead of the component, and verify that the same kind of behavior is not already installed before installing a new one. The problem is that when I install the behavior the component doesn't know its page. So I have to do something at this time, and then later when I know the page make sure that only one behavior is actually rendered. I see two solutions to this problem: - Add one timer behavior to each component (as today), and then when rendering the component use the wasRendered/markRendered methods of IHeaderResponse to render only one of them (using the isEnabled method to disable it if another similar one has already been rendered). But then I will have to update all the non rendered behaviors so that push events sent to them are actually sent to the only behavior which is rendered. - Modify the API of the push service and ask to enable push on a page before actually using push on components on the page. This would actually install a unique timer behavior on the page. Then when installing push on a component I could simply add something which could be located by the unique timer on the page to collect all push events (maybe a disabled behavior) Now that I expose the two options I think I prefer the first one. But I would like to gather feedback from experienced wicket developers to see if I'm not missing something or if you have better ideas about how to implement what I want. Hy Xavier, I've got an idea but I don't know if it will be convenient: TimerPushBehavior should not extends AjaxTimerBehavior. TimerPushBehavior could now do : - Adding a javascript(jsMain) in the header (using a static id - render once). This javascript can manage ajax timer on a specific callback url. - Each TimerPushBehavior registers its component id on the previous added javascript(jsMain) - When a callback is received by the first added behavior: * get all id registered in jsMain (sent to the behavior as parameters of the callbackUrl) * look for each child(server side) by they component id (IVisitor) * look for TimerPushBehavior on each child * call onTimer method on each TimerPushBehavior of each Child it is may be a little bit hacked but it can be a solution. WDYT? -- Vincent Thanks, Xavier
Re: wicketstuff-push: centralizing requests
On 7/11/07, Vincent Demay [EMAIL PROTECTED] wrote: Xavier Hanin wrote: Hi, I'm currently using wicketstuff-push to push events to a page and it works pretty well, but not well enough. Before trying to move to a comet based implementation, I would like to improve the timer based implementation. In the current implementation you got as many AjaxTimer as you install the push on components on the same page. So if you have three components requiring push, you will have three requests each x seconds, to poll for push events from the three components. This would be much more efficient if I had only one request polling for all push events sent by all components on the page... Hence my first thought was to add the timer behavior to the page instead of the component, and verify that the same kind of behavior is not already installed before installing a new one. The problem is that when I install the behavior the component doesn't know its page. So I have to do something at this time, and then later when I know the page make sure that only one behavior is actually rendered. I see two solutions to this problem: - Add one timer behavior to each component (as today), and then when rendering the component use the wasRendered/markRendered methods of IHeaderResponse to render only one of them (using the isEnabled method to disable it if another similar one has already been rendered). But then I will have to update all the non rendered behaviors so that push events sent to them are actually sent to the only behavior which is rendered. - Modify the API of the push service and ask to enable push on a page before actually using push on components on the page. This would actually install a unique timer behavior on the page. Then when installing push on a component I could simply add something which could be located by the unique timer on the page to collect all push events (maybe a disabled behavior) Now that I expose the two options I think I prefer the first one. But I would like to gather feedback from experienced wicket developers to see if I'm not missing something or if you have better ideas about how to implement what I want. Hy Xavier, I've got an idea but I don't know if it will be convenient: TimerPushBehavior should not extends AjaxTimerBehavior. TimerPushBehavior could now do : - Adding a javascript(jsMain) in the header (using a static id - render once). This javascript can manage ajax timer on a specific callback url. - Each TimerPushBehavior registers its component id on the previous added javascript(jsMain) - When a callback is received by the first added behavior: * get all id registered in jsMain (sent to the behavior as parameters of the callbackUrl) * look for each child(server side) by they component id (IVisitor) * look for TimerPushBehavior on each child * call onTimer method on each TimerPushBehavior of each Child it is may be a little bit hacked but it can be a solution. WDYT? Salut Vincent, The idea to use a specific javascript to handle the timer is interesting. Though ATM I've started implementing the first solution I suggested above, and it now works pretty well like this. So I think I'll stick with that for the moment, unless someone tell me there is a serious flaw in the approach I used. You will also be able to review what I've done when I'll commit it on wicketstuff-push, and revert or use another approach if there is a problem. BTW I'm having an issue with the timer, but I think it's a bug in the AbstractAjaxTimerBehavior implementation (I'll send another e-mail about this). Xavier -- Vincent Thanks, Xavier -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://incubator.apache.org/ivy/ http://www.xoocode.org/
