Hi Derell, there is no higher-level class (yet).
We decided to avoid too much magic and let the user explicitly select the transport method. Our main motivation was that we noticed the implicit selection of the transport confused a lot of users. The problem is that it's impossible to emulate all features of the Xhr transport in the script transport (not to speak about the iframe transport). For example, there is no (real) status code for script. With the transports clearly separated and documented, we hope the user is more aware of the differences. But we have not finally decided whether we will add an optional wrapper class. What do you think? Since io.request.Xhr and io.request.Jsonp have a common interface it should be possible to dynamically select the transport and still invoke the same methods. For example to support cross-domain requests in older browsers. qx.bom.request.Xhr#isCrossDomain may turn out useful. On the other hand, did you consider to let the user make the choice? Perhaps with the default being Xhr. Regards Tristan Am 19.05.2011 um 16:35 schrieb Derrell Lipman: > I am looking at the new qx.io.request.* classes to consider converting my RPC > simulator to use it. I am unable to determine, though, how the selection of a > transport is accomplished. In the old implementation, one instantiates a > qx.io.remote.Request object and sets a number of "needs" such as async or > not, expected response type, cross domain or not, etc. Those high-level needs > determine, at a much lower level, which transport is to be used > (XmlHTTPTransport, ScriptTransport, IframeTransport, or a transport added by > the user, such as the simulation transport). The new implementation seems to > be lower-level, leaving the selection of the transport up to the caller. Is > there a higher-level class that has not yet been written? What are the plans > here? > > Derrell > > <ATT00001..txt><ATT00002..txt> ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
