> I'm thinking of something simple as well. Perhaps along the lines of:
>
> var comm = new QxCommunicationsManager();
>
> // Set various properties in comm regarding target determination, event
> handlers and so on.
>
> comm.attach(button1, "execute");
> comm.attach(button2, "execute");
>
> And so on. In Qooxdoo style, events would be dispatched prior to and
> after sending the request, as well as on the response being received.
>
> What do you think?
Not sure. Personally, I think it looks like a lot of code for the end-user.
What I've done so far in my project amounts to a common method to all my
classes that I can call that looks like:
this.issueSystemCommand(cmdstring,_onSuccess,_onError);
basically, the way I've done things, the cmdstring contains info about how to
locate the relevant server code. The server code is executed and it responds
with javascript (not really JSON, but sort of, in as much as my code looks
for an object called 'response' to be present after executing whatever the
server sends back).
This all feels a bit hackish, but it's all very simple for me to use (about 3
lines of code) and I can add new communication "channels" with about an
hour's worth of work, mostly on the server-side.
Trying to follow my approach in any way, however, is pretty much not an option
since it all involves some knowledge of what's listening on the server.
I do think that you could get close to this level of simplicity using events,
though.
> I agree. I think the approach that I've outlined should accomodate your
> approach quite well.
My approach is that I've written a bunch of code on top of what amounts to a
string-in-string-out client-server communication channel. I'm the simplest
case, I think.
I think you might well be able to do much better but still be able to do it
with just a few lines of end user code.
> The idea with a plugin model would be that QxHttpTransport would have
> some additional properties. For instance:
>
> var transport = new QxHttpTransport();
> var comm = new QxCommunicationsManager();
>
> // Set various parameters for each of the above
>
> transport.setContentHandler(new QxJsonHandler()); // If anyone needs it,
> we could offer calls to have seperate objects to handle encoding the
> payload and decoding the response
> transport.setCacheHandler(new QxTransportCacheHandler());
> transport.setEventBinder(comm);
>
> Under this model, QxHttpTransport would execute methods of the content,
> cache and event binding handlers at the appropriate times.
>
> Of course, a similar concept with better execution is certainly possible.
To me, it seems a bit complicated. I'd leave QxHttpTransport as a
string-in-string-out channel and build on that.
In case it looks at all promising, have a look at the following:
proto._myHandlerFunc = function(e)
{
debug('got: ' + e.responseString);
};
var e = new ServerRequestEvent(myPayloadString,'ServerResponseEvent');
e.getHttpTransport().addEventListener("serverResponse",this._myHandlerFunc);
this.dispatchEvent(e);
The ServerRequestEvent could navigate the HttpTransport stuff without the user
having to know much about it. The nice thing is I'm back to my own code in
three lines.
Certainly, this assumes that something is listening for these events and will
handle them when dispatched. Presumably, this can be handled in some way
that doesn't require too much overhead.
To handle xml in and out, you'd just need two classes that extend the
string-based classes above as follows:
proto._myHandlerFunc = function(e)
{
debug('got: ' + e.responseDOM.firstChild.tagname()); // pseudo-code
};
var e = new DOMServerRequestEvent(myDOM,'DOMServerResponseEvent');
e.getHttpTransport().addEventListener
(
"serverResponseDOM",this._myHandlerFunc
);
this.dispatchEvent(e);
The QxCommunicationsManager was unnecessary, I think.
The nice thing about this approach is that the user doesn't have to think too
much about the mechanism and there's no presumption about what's on the
server.
There's certainly a bit more to think about, and maybe that's where a
QxCommunicationsManager might be appropriate.
You could preface your app's code (near where everyone sets the imagemanager
path) with:
QxCommunicationsManager.setUrl('index.php?do_ajax=1');
QxCommunicationsManager.setMaxConcurrentRequests(10);
Of course, this might complicate things for folks that use more than one url
for this stuff...might be a deal killer, not sure.
Anyway, just a suggestion from the less-is-more camp. :)
Regards and thanks for all you hard work,
--Fred
>
> Best regards,
>
> Chris
>
> > Regards,
> >
> > --Fred
> >
> > On Monday 16 January 2006 10:37 pm, Chris Ricks wrote:
> >> * Would the community prefer that these classes are clients of
> >> QxHttpTransport (effectively, wrapping QxHttpTransport for requests) or
> >> plugins to QxHttpTransport (effectively, being called when certain
> >> events occur)
--
==========================================================
Fred R. McDavid, III
540-248-0838
[EMAIL PROTECTED]
BitDaddy Systems, Inc
* Complex System Design, Management, and Hosting
==========================================================
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
