Hi, I don't know if I got the question right, but here's my take on it.
As far as I understand it, the sandbox should be the core API of the application. something like a facade for all relevant services in all modules. This means that whatever one module uses from another module, it has to be proxied by the sandbox. For instance, in the slideshow mentioned above, at slide 43 you can see that the sandbox has a method iCanHazCheezBurger() - that's something the sandbox implementer wanted to make available to all modules to query. You typically don't need to proxy lots of services. Access control info, some app-wide settings, maybe user information, but that should be it. Most of the rest of the information manipulated by your application should be pretty private to the module managing it. So your sandbox should indeed provide methods such as getUserRights(), getSetting(), getUserInfo() etc., but not setUserRights(), for instance - that one should be private to the access control management module. Specifically what gets into the sandbox public interface is something to be decided in each application individually. You have to think thoroughly about it - the sandbox is the hardest thing to change, once it is used from several modules. In order to be able to use the services provided by the sandbox, each module has to get a reference to the sandbox - that's why the registration mechanism passes the sandbox along. Specifically for events, the application core should provide a publisher/subscriber mechanism, but not tell a subscriber which publisher raised what event, nor allow a publisher to track who is subscribing to the events it emits. You could then have the code of your settings module to publish a layerStateChanged event, and have another module subscribe to that event. The settings management module wouldn't know it's coupled to the map (I suppose) module, and the map module wouldn't know it's reacting to a change caused by the settings module. However, in case you want to make it possible for the map module to directly query setting values, you need to provide a getSetting() function in the sandbox public interface. In particular, you can use qooxdoo's events mechanism to implement the publisher-subscriber mechanism in your sandbox. Does this get you any closer to a solution? > I've already see the slides and in slide 53 says "The application core > manage communication between modules". > So I assumed the communication between modules should be something like > this: > > Module X -> Sandbox X -> Core -> Sandbox Y -> Module Y > > But then I saw some samples of this architecture in qcl context which > confusing a little bit > > this.__sandbox = sandbox; > var yyy = yyy.module.AccessControl.getInstance(); > if ( ! yyy.sandbox ) yyy.sandbox = this.__sandbox; br, flj -- Fine counsel is confusing, but example is always clear. (Edgar A. Guest, The Light of Faith) ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
