On Thu, May 19, 2011 at 11:38, Tristan Koch <[email protected]> wrote:
> 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?
>
Hmmm... Transport is a low-level concept that I feel should be abstracted.
The interface that the user sees should be consistent regardless of the
transport in use. Although there are plenty of problems with the old
implementation, that's one area I think it really got right.
> 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.
>
If the user has to explicitly select a transport, then how is there a
default? Furthermore, if the interface for different transports is
different, I don't think you can have a default.
Yeah, I think we lose valuable functionality by removing the higher-level
construct, leaving only the low-level access to the transport.
Derrell
------------------------------------------------------------------------------
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
