On 5/11/07, Vincent Demay <[EMAIL PROTECTED]> wrote:
Hi
Xavier Hanin a écrit :
> Hey there,
>
> I have a question about the data "proxy" set to "true" in CometdEvent:
> what
> is it used for? Indeed I would like to get rid of CometdEvent, to make
> implementation switch very easy, but I'm not sure if all cometd events
> should always have this property set, or if only some should.
If I well remember I added this "proxy" value in CometdEvent to know if
an event has to be proxied by a behavior :
If you have a look at CometdDefaultBehaviorTemplate.js, I check if
proxy="true" before making a callback to the bahavior (var
wcall=wicketAjaxGet('${url}' + addToUrl, function() { }, function() {
});).
The aim is to make a différence between an event/publisher/behavior
architecture and a simple one(as in sharedForm) if cometd events are
sent on the same channel.
OK, now that I've investigated a little more the code I understand how it is
used.
The problem is that this is not really what I expected, because you don't
fully take advantage of comet: indeed each time an event is published on the
channel, it is sent to the server with only the parameters, then the client
send a regular ajax request to the server to get the actual UI
modifications. This means that you will have one connection for comet, plus
one connection for each comet event, which doesn't scale very well.
I thought we might be able to send directly the same content of the envelop
sent by wicket on the ajax call directly in the comet event data (the
envelop processed by Wicket.Ajax.Call.loadedCallback). In this case we would
be able to use the comet connection only, which would be much more scalable
IMO. This is not really what cometd is meant for, and it means this API
wouldn't be usable to send regular cometd events. So maybe I'm talking about
another implementation of a different concept, which could co exist with the
one you provided.
WDYT?
> If they all should have this data, I can do what I've already proposed
> in my
> patch (in a previous discussion on the user list). Otherwise the user
> will
> have to keep in control of this, and if it's suited to cometd
> implementaiton
> only, it will compromise my dream of transparent switching between
> implementations :-)
If you think it is better to remove that in order to deal with all event
in the channel, feel free to do it, but we need make user aware of that
in javadoc. (a cometdEvent triggered by an event/publisher/behavior
architecture can be intercept by a simple one in there are in the same
channel).
Yes, this is because you post regular comet events, which I didn't
understand first. It also explain why the channel listener do not have the
plain channel event, but only a map of strings. I think I'll need some more
thoughts because I think we are trying to achieve to different things: what
I need is server initiated refresh of the web page, using cometd (could be
only comet actually I think) for the transport (or polling in degraded
mode). What we have for the moment is something which allows to easily send
comet events, and on another hand easily react to these events on the client
side to trigger a regular ajax call asking for page refresh. In your case
any one can send the simple comet event, with proxy set to true, it will
trigger the refresh with another call to the server. In my case only the
wicket app can send a comet event with the envelop attached: it's only a
transport mechanism, nothing else. That's why I think comet could be enough,
no need for cometd. But I'm still not confortable enough with comet and
cometd to be sure of what I think.
So for the moment I will commit my changes as is, but I'd welcome opinion to
see if my use case and proposed implementation make sense.
Xavier
An other solution is to add it in timer implementation, even if it is
useless, it's up to you ;)
hope my explaination is clear ;)
--
Vincent
>
> TIA,
>
> Xavier
>
--
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/
