Sorry, but last question on this topic as I *almost* have it working now and I didn't understand your last reply: "I think this is just not the same... or?"
Question: With the new QxPostRequest what replaces the setRequestProperty() functionality? For example, I have a little servlet that returns xml data (http://foo:8080/bar) but it requires parameter x be called in the URL (eg. http://foo:8080/bar?x=val). Previously this was done via the call ajax.setRequestProperty("x", "val), how is this done with the new QxRequest object before send is called? >From your response I can't determine if it isn't implemented (which seems a little odd) or possibly it's planned for a future release. Thanks for your help, with this I will have completed the port to the new version (yay). Mike -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Werner Sent: Monday, February 20, 2006 12:22 PM To: [email protected] Subject: Re: [qooxdoo-devel] QxXmlHttpRequest Example Michael Wilson schrieb: > Are you saying that POST/GET parameter passing (as it was previously > handled by QxXmlHttpLoader.setRequestProperty) isn't implemented in > the latest version of Qooxdoo? If that is the case would string > concatenation on the url parameter be a viable workaround? I think this is just not the same... or? Sebastian > > Mike > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Sebastian Werner > Sent: Monday, February 20, 2006 12:14 PM > To: [email protected] > Subject: Re: [qooxdoo-devel] QxXmlHttpRequest Example > > Michael Wilson schrieb: >> Thanks for your quick reply. I have looked at Transport_1.html and >> it > >> isn't actually calling a web service, only local XML files. > > I don't see why this makes any difference. You can choose between > QxPostRequest and QxGetRequest. Choose what you like. > > >> Additionally, the example doesn't show how to set the POST parameters >> such that they are passed to the service. I guess my question would > be >> then how would I write the code below using QxRequest then? > > Headers are currently not implemented on the QxRequest level. I am > sorry. We could really need some help to get this new, better > implementation more feature complete. > > Sebastian > >> I will continue to tinker but I have already spent a few hours trying > to >> get this to work and have had no luck. Probably just my lack of >> understanding of JS. If I can't figure it out soon I will revert >> back to the previous version of Qooxdoo till an example can be posted. >> >> Mike >> >> >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of >> Sebastian Werner >> Sent: Monday, February 20, 2006 11:59 AM >> To: [email protected] >> Subject: Re: [qooxdoo-devel] QxXmlHttpRequest Example >> >> Michael Wilson schrieb: >>> Sorry, made a mistake in the original post. I guess you didn't >>> deprecate the XmlHttpRequest object (no more AJAX then). What was >>> deprecated was the QxXmlHttpLoader. Previously I was using like > this: >>> function foo() { >>> var ajax = new QxXmlHttpLoader(); >>> >>> //assuming async >>> ajax.requestMethod = "POST"; >>> ajax.setRequestProperty("foo", "bar"); >>> ajax.load("http://cpu:8080/myurl";); >>> >>> } >>> >>> I haven't been able to figure out what the equivalent of this code >>> would be using the new objects recently released. Does anyone have >>> a > >>> small example for a noobie? >> There is a transport example in our demo folder >> "demo/example/Transport_1.html". You must not use QxXmlHttpLoader, >> but QxRequest. >> >> Hope this helps. >> >> Sebastian >> >> >>> I've tried: >>> function foo { >>> // data >>> var ajax = new QxXmlHttpTransport(); >>> >>> ajax.setMethod("POST"); >>> ajax.setData("show", "beo"); >>> ajax.setUrl("http://sparta:8080/oxml/query/cboFolder.oxml";); >>> ajax.send(); >>> } >>> >>> I get an error: "Failed: ...XMLHTTP is not supported". Anyone have >>> any ideas? This Url works if I revert back to the previous >>> QxXmlHttpLoader object. I can revert back >>> >>> Mike >>> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of >>> Michael Wilson >>> Sent: Friday, February 17, 2006 7:39 PM >>> To: [email protected] >>> Subject: [qooxdoo-devel] QxPostRequest Example >>> >>> 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=1216 >>> 42 >>> >>>>>> _______________________________________________ >>>>>> 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=1216 >>> 42 >>>>> _______________________________________________ >>>>> 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=1216 >>> 42 >>>> _______________________________________________ >>>> 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=1216 >>> 42 _______________________________________________ >>> 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=k&kid3432&bid#0486&dat1642 >>> _______________________________________________ >>> 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=k&kid3432&bid#0486&dat1642 >>> _______________________________________________ >>> 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=1216 > 42 >> _______________________________________________ >> 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=k&kid3432&bid#0486&dat1642 >> _______________________________________________ >> 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=1216 > 42 _______________________________________________ > 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=k&kid3432&bid#0486&dat1642 > _______________________________________________ > 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
