Hi Fred,
Fred McDavid wrote:
Hi Chris,
I think the work on "Helpers for sending client-side event data to server-side
code" could really make the posted question (and other,
implementation-specific questions like it) a purely academic one.
Seems like to me (just brainstorming), an ideal approach for the helpers thing
would be something that would allow me to write code that, in the simplest
case, looks like:
proto._myHandlerFunc = function(e)
{
debug('got: ' + e.responseString);
};
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?
QxCommunicationsManager.addEventListener("serverResponse",self._myHandlerFunc);
this.dispatchEvent(new
ServerRequestEvent(myPayloadString,'ServerResponseEvent'));
xml-out-xml-in could look like:
proto._myHandlerFunc = function(e)
{
debug('got: ' + e.responseDOM.firstChild.tagname()); // pseudo-code
};
QxCommunicationsManager.addEventListener("serverResponseDOM",self._myHandlerFunc);
this.dispatchEvent(new DOMServerRequestEvent(myDOM,'DOMServerResponseEvent'));
How that all gets done on the backend is really more of a
performance/stability issue from my perspective.
I agree. I think the approach that I've outlined should accomodate your
approach quite well.
With all that said, however, I'd be interested in seeing some pseudo code
showing plugin vs. client. I'm not sure I understand what the plugin model
would involve.
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.
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
