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/
