Fred McDavid wrote:
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.
I agree, that in some cases it could end up resulting in a fair bit of
code being written, but read on. :-)
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.
That would be the idea. Effectively, QxCommunicationsManager (or
whatever it gets called) would listen to events on certain widgets (or
other Qooxdoo objects) and post them to the server as appropriate. This
may very well end up being quite simple, as:
* One would not need to modify any Qooxdoo objects
* A single QxCommunicationsManager instance could handle calls for
multiple widgets / Qooxdoo objects
* Payload-handling and target-determination code could be generalised
or, at least, easily reused (by way of events and being able to
determine the source of the event).
The idea definitely needs more refinement, but I think you and I are
thinking along the same lines.
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.
That will definitely be the aim.
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.
Or it might not. Setting an event to be fired prior to dispatch to allow
the user's code to determine the target would solve that problem cleanly
I would think. For the system we're working on, objects exist on each
side of the client-server divide, and all we're really doing is ensuring
each side is always in sync with the other.
Anyway, just a suggestion from the less-is-more camp. :)
A suggestion that's greatly appreciated. Doing encoding/decoding and
event handling in a single class wasn't my intention - the class I do
have in mind would probably end up providing a Qooxdoo-standard
interface to do what you're currently doing if things turn out the way
I'm working toward. I'll get some use cases together and we can go from
there.
Best regards,
Chris
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)
--
Chris Ricks - BE (Melb)
Lead Software Engineer
IT Operations
Phone: 1300 722 388
Mobile: 0433 276 911
E-mail: [EMAIL PROTECTED]
begin:vcard
fn:Chris Ricks
n:Ricks;Chris
email;internet:[EMAIL PROTECTED]
tel;work:1300 722 388
tel;cell:0433 276 911
x-mozilla-html:FALSE
version:2.1
end:vcard
