Hi all,
I've now had time to have a read through the code in the "transport"
directory within the source tree. Firstly, I'm quite flattered by the
familiarity that I feel when reading through some of that code. :-P
Looking at the code that I've written and the code that Sebastian has
written, it wouldn't be too hard for me to adapt my stuff to do what
Sebastian intends. That said, there's a problem that pops up if we do
try to group standard HTTP-style requests, hidden IFRAME requests and
XmlHttpRequest objects into a single class tree - the advantages of
inheritance disappear to a large degree.
For example, there's no way of firing off most events that are relevant
to XmlHttpRequest for the other types. Admittedly though, the other
types have advantages (such as being able to make requests to domains
other than the one the script is hosted on).
Sebastian, it may be asking a bit much, but if you could tell me how you
want me to fit QxHttpRequest into the scheme of things, then I'll get to
work. Looking at what you've got in place, basically you want me to fit
it into the QxRequest-rooted tree, issue QxResponse objects on response
and use your new queuing system.
These aren't too hard, but:
* Your new queuing system is timer-based, whilst mine is event-based.
Personally, I prefer (and would recommend everyone look into)
event-based queuing, as it tends to be easier to understand, easier to
debug and more efficient.
* (Please don't take this as anything but a suggestion / question) -
There are definitely advantages to having POST, GET and IFRAME requests
as options next to XmlHttpRequest, but should they really exist in the
same tree? A lot of XmlHttpRequest functionality can not be accessed
through the other methods, meaning that a large number of methods are
QxXmlHttpTransport-specific. I'm open to answers and supporting detail
here - as the great Larry Wall said, "be wary those who profess to know
the one true way".
As always, please send all questions and feedback for prompt, thought
out responses. :-)
Sebastian continues to do brilliant work - the fact that he's obviously
taken the time to look at my contribution is quite flattering and I hope
it's a trend that I can give reason for continuing.
Best regards,
Chris
Sebastian Werner wrote:
Hi all,
we think there were really great discussions on what features a new
AJAX layer of qooxdoo should have. I have now started to create a new
one, which is based on many ideas of Chris Ricks. Thank you again Chris.
We have some other ideas added. We want a special request (QxRequest)
and response (QxResponse) object to handle the data between the
different communication layers in qooxdoo. Also we think to have a
queue is great. But we think it is better placed outside the xmlhttp
related stuff. We have done this in our new class QxRequestQueue. This
class create instances of the class QxTransport which handles the
wrapping to the different transport implementations. For example this
could be the classical xmlhttp (QxXmlHttpTransport) or iframes
(QxIframeTransport).
This concept allows us to add new transport implementations easily if
they appear on the horizon.
There are some possibilities of Chris Ricks work missing. Like
timeouts for example. This is something I think should be placed in
QxRequestQueue, too. QxRequestQueue is somewhat basic currently and
does no real queuing.
As I have no more time to work on these classes before the final
release of the next version of qooxdoo, this will be also the versions
of the release. Afterwards we will continue the work. You are all
invited to help. Chris, sorry, I hope I have not dis encouraged you
with our plans and decisions. I would really like it, if you could
help us, to extend and modify the newly existing stuff to your needs.
For any further work, please keep the new code more prototype style
and try to omit to send complete full-working classes. We should
really discuss the additions and changes in detail before coding them.
Thanks.
Best regards,
Sebastian
-------------------------------------------------------
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
-------------------------------------------------------
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
