Since we're at it, I really would like to hear from others (if there is any interest at all, of course), how they would implement this architecture the qooxdoo way.
How, for example, would one deal with building the UI parts of the modules? If we're serious about not using the global namespace, and would like to prevent the modules from doing bad things, one would have to pass a "dummed-down" version of the qx object tree to the Sandbox or to a special "build" method of the module, which then returns the UI objects that belong to the module. The main parts simply pieces together these parts into the final UI. Looking at the Sandbox API (see link in my last email), it also occurs to me that this API is still quite inconsistent. For example, modules should not be able to call the authenticate() method - that's the Core's job in the main function - triggerable by passing a message to a subscriber defined in "main". It's all not very well thought through, more a thought experiment. But it is in the logic of the coming "strict mode", which builds on the assumption that you radically limit the access of functions to outer variables and only pass around the objects that are needed. It would also make it easiert to reuse whole parts of applications in different contexts or apps. C. -- View this message in context: http://qooxdoo.678.n2.nabble.com/qcl-access-demo-application-tp6295025p6347161.html Sent from the qooxdoo mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
