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.
Well, you migrate from a at least 5 year old qooxdoo version to the current
development. I hope you understand that some APIs changed over these long time
period and some of the decisions made during that time might be not the best
decision from todays view, even if they were the right thing to do back then.
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
I understand that this change is annoying for you. But this class was marked as
experimental which means use at your own risk and we do not consider it ready
for production. This also means we can remove the class without any deprecation
because its experimental.
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.
I don't think its good to start a discussion on the mailing list and in a bug
report:
http://bugzilla.qooxdoo.org/show_bug.cgi?id=6064
Please check the discussion there and see my detailed posts on former questions
there.
Regards,
Martin
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
