Hi Andreas > Hi, Christian, > > good to hear that you seriously consider migrating to future qooxdoo > versions, i.e. namespaces-based qooxdoo. ;-)
Of course, I would like to stay with the cutting edge of qooxdoo development. But once one seriously invests in a certain version, learning the internals, building custom extensions and a whole application on it, then migrating migrating means... you can imagine.... [...] > 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 Now this is an interesting javascript question: is there any situation in which an object created with the reference to a prototype instead with the prototype itself could behave differently, i.e., isn't QxButton = qx.ui.form.Button; myButton1 = new QxButton; always the same as myButton2 = new qx.ui.form.Button; How would the objections you give above matter if the developer is aware of the original namespaced names? I would prefer to leave my code as is instead of applying the migration scripts (and making it larger in the process) if I can just put the "compatibility layer" in between - that is why I also call for utmost API compatibility (at least as it doesn't compromise new features). I know that there are parts of the code that need to be rewritten in any case. > 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()? ... Guess why I like to do visual widget creation with qooxdoo so much better than with dojo ;-) I just use dojo's transport API. And I did write my own wrapper using at MOST three levels of namespaces (such as zophe.event.dispatch) for business logic only (not for widgets). > 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. As I said, I do recognize the elegance and logic behind the concept. But I am a lazy, pragmatic coder with little time and a long todo-list and as long it doesn't give me any clear advantage writing code, I'd rather stay with the messy old ways... ;-) Cheers, 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
