The experimental ScriptLoader has been removed. Please use 'qx.bom.request.Script' instead

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

The experimental ScriptLoader has been removed. Please use 'qx.bom.request.Script' instead

Peter Schneider
Hi there,

I've noticed that Bug #6064 removes the qx.io.ScriptLoader class in favor of
qx.bom.request.Script.
What is the _real_ reason for that?

I am asking because the API of qx.bom.request.Script is "very poor" compared
to the (experimental, but perfectly working) qx.io.ScriptLoader.

1. I think that a ScriptLoader fits very well in the 'io' namespace
2. qx.io.ScriptLoader#load() method had the convenient 'context' parameter.
3. This "replace the member-method" style is something I don't like very much.
   The naming for that methods[2] e.g. is soooo not qooxdoo (camel case?!)


Anyway, is the following migration correct? The 'old' callback did get a
'status' parameter, what do I do with that? Do I have to handle onerror,
onabort, ontimeout, onloaded and onload all by myself?

--- old ---
<code>
// __onComplete : function (status) { ... }

  var loader = new qx.io.ScriptLoader();
  loader.load(url, this.__onComplete, this);

</code>
--- new ---
<code>
// __onComplete : function () { ... }
// __onFailure : function () { ... }

  var loader = new qx.bom.request.ScriptLoader();

  // Which one?
  loader.onload = qx.type.Function.bind(this.__onComplete, this);
  loader.onloaded = qx.type.Function.bind(this.__onComplete, this);

  // do we have to replace _all_ of them?
  loader.onerror = qx.type.Function.bind(this.__onFailure , this);
  loader.onabort = qx.type.Function.bind(this.__onFailure, this);
  loader.ontimeout= qx.type.Function.bind(this.__onFailure, this);

  // "GET" or "POST" ? I don't know/care
  loader.open("GET", url);
  loader.send();
</code>

Thanks for any insights on this,
  Peter



[1] http://bugzilla.qooxdoo.org/show_bug.cgi?id=6064
[2] onreadystatechange, onload, onloadend, ...
    These look more like any "cheap" DOM/BOM manipulation Library, not like
    the qooxdoo OO-style I love so much!

--

*************************************************************
Besuchen Sie uns:
01.-03.10.2013 Post-Expo in Wien
Wir laden Sie herzlich ein und freuen uns auf Ihre Anmeldung.
*************************************************************

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: The experimental ScriptLoader has been removed. Please use 'qx.bom.request.Script' instead

Thomas Herchenroeder
Daniel will probably give you a better answer, but here are just some
aspects touching on what you wrote:

* We wouldn't want to duplicate (nearly) identical logic in the framework.
* qx.bom.request classes have all the same interface (so are easily
exchangeable).
* The interface is the W3C interface. Yes, that's not our style, but we
thought conformance with the released spec outweighs "local" style
considerations, so everybody in the JS community can speak the same
language.

T.

On 09/12/2013 09:57 AM, Peter Schneider wrote:

> Hi there,
>
> I've noticed that Bug #6064 removes the qx.io.ScriptLoader class in favor of
> qx.bom.request.Script.
> What is the _real_ reason for that?
>
> I am asking because the API of qx.bom.request.Script is "very poor" compared
> to the (experimental, but perfectly working) qx.io.ScriptLoader.
>
> 1. I think that a ScriptLoader fits very well in the 'io' namespace
> 2. qx.io.ScriptLoader#load() method had the convenient 'context' parameter.
> 3. This "replace the member-method" style is something I don't like very much.
>     The naming for that methods[2] e.g. is soooo not qooxdoo (camel case?!)
>
>
> Anyway, is the following migration correct? The 'old' callback did get a
> 'status' parameter, what do I do with that? Do I have to handle onerror,
> onabort, ontimeout, onloaded and onload all by myself?
>
> --- old ---
> <code>
> // __onComplete : function (status) { ... }
>
>    var loader = new qx.io.ScriptLoader();
>    loader.load(url, this.__onComplete, this);
>
> </code>
> --- new ---
> <code>
> // __onComplete : function () { ... }
> // __onFailure : function () { ... }
>
>    var loader = new qx.bom.request.ScriptLoader();
>
>    // Which one?
>    loader.onload = qx.type.Function.bind(this.__onComplete, this);
>    loader.onloaded = qx.type.Function.bind(this.__onComplete, this);
>
>    // do we have to replace _all_ of them?
>    loader.onerror = qx.type.Function.bind(this.__onFailure , this);
>    loader.onabort = qx.type.Function.bind(this.__onFailure, this);
>    loader.ontimeout= qx.type.Function.bind(this.__onFailure, this);
>
>    // "GET" or "POST" ? I don't know/care
>    loader.open("GET", url);
>    loader.send();
> </code>
>
> Thanks for any insights on this,
>    Peter
>
>
>
> [1] http://bugzilla.qooxdoo.org/show_bug.cgi?id=6064
> [2] onreadystatechange, onload, onloadend, ...
>      These look more like any "cheap" DOM/BOM manipulation Library, not like
>      the qooxdoo OO-style I love so much!
>


------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel