Hi, Christian, good to hear that you seriously consider migrating to future qooxdoo versions, i.e. namespaces-based qooxdoo. ;-)
> To be a bit more constructive than in my last email: When I find the > time, I'll try to build a "compatibility layer" script which can build > on the migration scripts that the developers have provided. It should be > fairly easy to convert them into a javascript file which creates > shortcuts such as "QxButton = qx.form.Button;" etc. This would > significantly ease the pain during migration or even offer a permanent > solution for those who want to keep working with the old names. I'd like to comment on this. While it is a fair option for any user to create any convenience wrappers to qooxdoo, it is generally not a good idea for several reasons. - It is just a one-time solution, you have to keep your wrappers in-sync with any relevant qooxdoo changes - You probably lose major features of the upcoming build process (compiling, linking, deploying, api generation, ...) as it can no longer rely on fully qualified class names - Namespaces provide a hierarchy that lets developers more easily understand and organize class-based code (both qooxdoo and custom code) - You cannot easily use qooxdoo's comprehensive auto-generated api reference Anyway, since you use dojo as well, you probably don't think about providing a wrapper for dojo namespaces, do you? ;-) If namespaces are such a pain, why not wrap for example dojo.event.topic.registerPublisher() into something like DjRegisterPublisher()? I think that users will finally get over qooxdoo namespaces. At first we didn't like the verbosity of namespace-based classes ourselves, but once you think it over and actually use it, it clearly is superior. SCNR, ;-) Andreas > Christian Boulanger schrieb: > >>Chiming in here: >> >>I understand the elegance of the namespacing concept, but I never quite >>understood what the REAL advantage was. Global namespace pollution is a >>relatively small concern in a javascript environment, and chances that >>another toolkit uses the "QxFoo" class name pattern are almost nil. For >>me at least, there is no practical advantage in the new pattern, on the >>contrary -- to be honest ---, I find it quite annoying. (please don't >>take an offense - I LOVE qooxdoo). >> >>I am still in favor of (at least optionally) keeping good old QxFoo >>classes as shortcuts to the extremely verbose new names and if I ever >>move to the new branch, this will be the first thing I will create. >> >>Best, >> >>Christian ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
