I just updated my source tree to the .5 version of Qooxdoo which deprecates the XmlHttpRequest object. Previously I had used the .setRequestProperty of this object to set POST parameters. Can't seem to figure out how to do the same thing with the new code. Does anyone have an example of this or, even better, a small chunk of code showing usage including what used to be the .load function?
Thanks. Mike -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Ricks Sent: Friday, January 27, 2006 6:53 AM To: [email protected] Subject: Re: [qooxdoo-devel] Progress of new AJAX layer in qooxdoo Hi Sebastian, Sebastian Werner wrote: > Chris Ricks schrieb: >> 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 > > Yes sure, parts of the code is copied (but modified) from your code. I'm glad some of it was useful! > >> >> 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. > > Fact is that you, as the later user of the library have no interest in > what object you are using internally. I don't see why "the advantages > of inheritance disappear to a large degree" should be true. We have > separated each technology as much here from the other ones. This is in > my opinion a much better approach than handling queuing and timeouts > all in one (or two strongly dependent) classes. Certainly it's true > that if you handle it your way you can support all the stuff which > each transport layer can handle inside the same object. This means the > queuing could be done easier to handle purely xmlhttp than different > layers as each layer must be compatible to the others (the must use > some common standard). My reasoning behind the solution I presented was based on the idea of having a simple queue framework - reimplementing the queue is fairly trivial if required (to add different queuing disciplines). Keeping everything to do with the actual request in a single class makes it easier to keep track of what events and timers need to be dealt with at each state change. Additionally, requests that are not part of a queue are supported. Effectively, to make the queuing class the active entity, it would simply require that the queue class itself assign actual transport means to each request as issuing begins. At present, my solution has a global pool of XmlHttpRequest objects that are used as required (and expanded only if needed). This supports multiple queues as well. To change this to fit with a queue-as-active scheme, I'd really just have to factor-out the XmlHttpRequest-assignment code and provide a queuing class that listens for state changes and populates QxResponse objects as required. Not that hard really. > >> >> 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). > > Doing it our way here is more qooxdoo style. As it tries to build > common APIs for different stuff. Surely your xmlhttp or iframe object > must have API features which are normally not directly useful or > available in this object but make it easier to build an common API > layer above this implementations. Definitely. The richness that XmlHttpRequest affords over IFRAME methods was the basis of my statement here. > > > This idea was also behind our event and focus handling and many other > parts in qooxdoo. If a object have no such event we try to fix it our > own way. This let the qooxdoo application developers assign > doubleclicks without knowing about the forty lines of codes qooxdoo > needs to make this event really useful in cross-browser environments. > >> >> 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. > > Our new queuing system is basically not existent. It was just there to > fill the space in our UML diagram. It is timer-based just because this > was the easiest method to get an initial version done. I have invested > much more time in the communication between the layers than for the > implementations of the classes them self. > >> * (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". > > I don't see why you want to put POST, GET (which are http methods) to > the same level as the implementation (IFRAME). > > In my opinion it must also be possible to handle POST requests with > iframes. It's a bit more complex that in doing the same in xmlhttp, > but it should be possible using a typical form submits where the > target is the iframe later. > >> >> 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. > > We hope so :) I'll look over the code in transport/ properly. I'll come up with a proposal for maintaining and enhancing the stuff over the next few days if you're interested. :-) > > Sebastian > >> >> 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 > > > > ------------------------------------------------------- > 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 ------------------------------------------------------- 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&kid3432&bid#0486&dat1642 _______________________________________________ Qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
