Hey,

I have recently started to port my web desktop from QooxDoo 0.7 to 3.0 
and I have to say that I have not yet come to the point to appreciate 
all of the changes in the API.

With that said, I replaced my homegrown code for loading scripts in 0.7 
with qx.io.ScriptLoader and in 3.0.1 it seems I'll have to replace this 
again with qx.bom.request.Script

Can we re-visit this decision please ? I want to use a clean API and do 
not  want to get into discussions about bom ( Browser Object Model ) as 
the low-level API below the high level abstraction implementation ( 
qx.io.* et al ).

I read the arguments for this change and I think they are invalid from 
an end-users point of view. Remember to always listen to your customers :).

 > 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.
Yes, we want to if it makes sense. In this case it does make sense. BOM 
= Browser Object Model and has nothing to do with a high level 
application API. qx.io.* however has everything to do with my 
applications Input/Output. So I build my applications using this API in 
the hopes that QooxDoo will keep this high level API even if the 
browser(s) would decide to change their object models.

 > * qx.bom.request classes have all the same interface (so are easily 
exchangeable).
Not true. I am missing the ScriptLoader.load () function and its ease of 
use. Yeah I can replace it with 5 lines of code but the API is UGLY as 
compared to ScriptLoader.

 > * 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.
This logic is ill conceived. I use QooxDoo to do things easier. 
Otherwise I may as well go to pure JavaScript or jQuery because this is 
what 'everybody in the JS community can speak'.

I believe that most people using QooxDoo are doing so because they find 
the QooxDoo style of OO programming cleaner and easier to use. Why would 
we want to change that point ?

Please reconsider this change and keep the high level API as functional 
and easy to use.

Thanks

Varol

------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to