Each module should only to communicate with it sandbox, using methods like
subscribe and publish. So if a module need communicate with the others, the
sandbox will do that job.
But my point was how should sandbox do it?
As far as I could understand until now, one way to do that is to turn public
the methods of each modules which I need access from another modules, and
then use getInstance to access the module.
Does anyone have a better idea?
2011/5/10 panyasan <i...@bibliograph.org>
> 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
>
------------------------------------------------------------------------------
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
