Xavier Hanin a écrit :
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.
Yes exactly, With this way we can have different behaviors on differents
pages according to the data coming from the event. But it is
definitively not very scalable.
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.
I think it can be an other approach, sending directly in the event
xmlFragment, javascript etc.. . but this kind of data are not very
regular cometd events. CometD is supposed transport json, so data
embedded in a serialized javascript object. The question is can we
consider xmlFragment is a part of a json object value?
I see An other problem : Using this approach means we know in the
eventPublisher the page structure, so it is impossible to send event to
different pages. And the event is directly very linked to the HMI.
WDYT?
--
Vincent
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
>
