cometd-javascript wrapper for qooxdoo library

[panyasan]

Hi,

I just wanted to let you know that I released an alpha version of a
wrapper for cometd-javascript for the qooxdoo toolkit (http://
www.qooxdoo.org). It is available only in CVN currently

https://qooxdoo-contrib.svn.sourceforge.net/svnroot/qooxdoo-contrib/trunk/qooxdoo-contrib/cometd/trunk/

and still depends on a minimal dojo library for the transport. These
dependency will eventually be replaced by qooxdoo transport bindings.

Thanks for your work on the javascript client.

Christian

[Simone Bordet]

Christian,

Great to see the binding for qooxdoo as well !

The other news is that I rewrote the transport part to allow pluggable
transports, and now the bindings are a little different.
They're more object oriented, so it should fit well with qooxdoo
support for object hierarchies.

I'm glad to support you in the conversion, but my knowledge of qooxdoo
is quite limited.

Plus, we'll release 1.0 final soon, so it may be worth to change so
that it adapts to the new pluggable API from the start.

Cheers,

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

[panyasan]

Simon:

On 7 Okt., 15:10, Simone Bordet <simone.bor...@gmail.com> wrote:
> The other news is that I rewrote the transport part to allow pluggable
> transports, and now the bindings are a little different.
> They're more object oriented, so it should fit well with qooxdoo
> support for object hierarchies.

That is good to hear. I guess the new code is in SVN and 1.0rc0 is not
up to date?

> I'm glad to support you in the conversion, but my knowledge of qooxdoo
> is quite limited.

No problem, I am not an expert, but know the framework (and helpful
experts)
well enough to get it done with your help. The current wrapper is
here:

https://qooxdoo-contrib.svn.sourceforge.net/svnroot/qooxdoo-contrib/trunk/qooxdoo-contrib/cometd/trunk/source/class/cometd/Client.js

As you can see, it is a *very* thin wrapper, the main trick will be to
map the transport code. In particular, what is the exact nature of
the return data "return deferred.ioArgs.xhr" ? I don't think there is
an equivalent in qooxdoo for that.

I have been successful in porting the chat demo application:

https://qooxdoo-contrib.svn.sourceforge.net/svnroot/qooxdoo-contrib/trunk/qooxdoo-contrib/cometd/trunk/demo/chat/source/class/cometd/chat/Application.js

It works well with the jetty implementation of the cometd server. I
have been unsuccessful to install neither the python or perl server,
unfortunately (see my other post).

Please let me know where to find the new code and I'll try to work it
into the qooxdoo implementation.

Thanks for your work,

Christian

[Simone Bordet]

Hi,

On Wed, Oct 7, 2009 at 15:51, panyasan <c.bou...@gmx.de> wrote:
>
> Simon:
>
> On 7 Okt., 15:10, Simone Bordet <simone.bor...@gmail.com> wrote:
>> The other news is that I rewrote the transport part to allow pluggable
>> transports, and now the bindings are a little different.
>> They're more object oriented, so it should fit well with qooxdoo
>> support for object hierarchies.
>
> That is good to hear. I guess the new code is in SVN and 1.0rc0 is not
> up to date?

Exactly. rc0 does not have the latest code, and we figured out better
before 1.0 than after that to do such a change.

>> I'm glad to support you in the conversion, but my knowledge of qooxdoo
>> is quite limited.
>
> No problem, I am not an expert, but know the framework  (and helpful
> experts)
> well enough to get it done with your help. The current wrapper is
> here:
>
> https://qooxdoo-contrib.svn.sourceforge.net/svnroot/qooxdoo-contrib/trunk/qooxdoo-contrib/cometd/trunk/source/class/cometd/Client.js
>
> As you can see, it is a *very* thin wrapper, the main trick will be to
> map the transport code. In particular, what is the exact nature of
> the  return data "return deferred.ioArgs.xhr" ? I don't think there is
> an equivalent in qooxdoo for that.

I am not sure I follow.
That return statement returns the XHR used in the bayeux request.

Also, I would find a way to not replicate all org.cometd.Cometd
methods. Can you just extend from org.cometd.Cometd ? Or actually just
do:
cometd.Client = new org.cometd.Cometd();

See for example jQuery bindings here:
http://svn.cometd.org/trunk/cometd-javascript/jquery/src/main/webapp/jquery/jquery.cometd.js

> I have been successful in porting the chat demo application:
>
> https://qooxdoo-contrib.svn.sourceforge.net/svnroot/qooxdoo-contrib/trunk/qooxdoo-contrib/cometd/trunk/demo/chat/source/class/cometd/chat/Application.js
>
> It works well with the jetty implementation of the cometd server. I
> have been unsuccessful to install neither the python or perl server,
> unfortunately (see my other post).

Unfortunately I have no knowledge of those servers.

> Please let me know where to find the new code and I'll try to work it
> into the qooxdoo implementation.

It's in SVN trunk:
http://svn.cometd.org/trunk/cometd-javascript/

You can look at the bindings for dojo and jquery, or even look at the
test case for a custom transport:
http://svn.cometd.org/trunk/cometd-javascript/jquery/src/test/java/org/cometd/javascript/jquery/CometdTransportTest.java

Not sure if qooxdoo has its own XHR and JSONP facilities, but if it
has them, you can remove the dependency from dojo simply by writing a
pure qooxdoo binding.

Let me know if I can help.

[panyasan]

Simon:

On 7 Okt., 19:28, Simone Bordet <simone.bor...@gmail.com> wrote:
> Exactly. rc0 does not have the latest code, and we figured out better
> before 1.0 than after that to do such a change.

I will try to update to the SVN code as soon as I get to it.

> > As you can see, it is a *very* thin wrapper, the main trick will be to
> > map the transport code. In particular, what is the exact nature of
> > the  return data "return deferred.ioArgs.xhr" ? I don't think there is
> > an equivalent in qooxdoo for that.
>
> I am not sure I follow.
> That return statement returns the XHR used in the bayeux request.

Ok, the raw XMLHttpRequest object then. I have to figure out where
qooxdoo stores this object internally, since it is not returned by the
equivalent qooxdoo API method.

> Also, I would find a way to not replicate all org.cometd.Cometd
> methods. Can you just extend from org.cometd.Cometd ? Or actually just
> do:
> cometd.Client = new org.cometd.Cometd();

No that is not possible. qooxdoo has its own class definition syntax,
which allows for a very powerful class/interface/mixin architecture,
but at the same time it is not possible to simply extend native
javascript objects. Also, wrapping the code like this allows to use
the qooxdoo API documentation tools. I will probably also change the
parameter signature of some functions to adapt the API to closer
resemble the qooxdoo usage. For example, the context object of
callback functions in qooxdoo is typically provided after the
function, not before.

Thanks,

Christian

[Simone Bordet]

Hi,

On Thu, Oct 8, 2009 at 12:37, panyasan <c.bou...@gmx.de> wrote:
> Ok, the raw XMLHttpRequest object then. I have to figure out where
> qooxdoo stores this object internally, since it is not returned by the
> equivalent qooxdoo API method.

From the current implementation, it uses dojo, so you don't have to do
nothing special.
But if you want to use qooxdoo xhr then yes, you have to figure out
where is the xhr object and return it.