I've already understand the logic which module only access to the sandbox
and the sandbox have access to the core.
But in major web applications modules needs information about each others.
For example an event is fired in module x that have to execute something in
module y.
In my project for instance, if I check a layer in a module of layers, that
layer have to appear in map which is another module.
I just want to know the best way to do that. I know that no module is
allowed access to other modules, so module have to publish "something"
in sandbox, but then what should sandbox do?
sandbox X -> Core -> Sandbox Y
or
sandbox X -> sandbox Y (public)
*I hope I have made* my *point more clear.*
**Thanks for all
Ana Rita Sousa
2011/5/10 panyasan <i...@bibliograph.org>
>
> arsousa wrote:
> >
> > 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?
> >
>
> I don't know if I fully understand your objection, but in the
> core-sandbox-module architecture, the very point is that no module is
> allowed access to other modules. Each sandbox has access to the "Core", and
> can this way communicate with the core, which does all the sensitive stuff,
> and can talk to other Sandboxes. But the module has no access to the Core,
> it can only use the Sanbox API to do things. That's why the "Core" object
> needs to be declared outside the application class, and then be used as a
> closure variable.
>
> Of course the question is if you need all these security mechanisms for
> your
> particular purpose. Most qooxdoo apps do just fine without them. But it
> would be senseless to try to overcome the "firewall" between module and
> core
> which is the main idea of the whole architecture. But maybe I misunderstood
> your point.
>
>
> --
> View this message in context:
> http://qooxdoo.678.n2.nabble.com/qcl-access-demo-application-tp6295025p6348222.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
