There is a discussion on this list about the core-sandbox issue some months
back, and the gist of the discussion was that since qooxdoo applications are
usually monolithic and do not integrate untrusted code, this architecture
was not needed. However, I think that there might be use cases where
creating sandboxes becomes necessary - i.e. in bigger apps that allow
plugins that might come from untrusted sources.
I don't know if I really implemented what Nicolas had in mind and would be
interested in feedback. Here's the basics:
You define the "core" variable outside the main class definition, and then
assign an instance of qcl.application.Core() in your main() method.
qcl.application.Core() has a nice API to do all kind of things.
/**
* The core application object
* @type qcl.application.Core
*/
var core;
qx.Class.define("xxx.Application",
{
extend : qx.application.Standalone,
[...]
main : function()
{
[...]
/*
* application core providing application functionality
*/
core = new qcl.application.Core();
/*
* create and show popup
*/
core.createPopup();
core.showNotification(this.tr("Starting application..."));
/*
* initalize server communication, access and config
*/
core.setServerUrl("../services/server.php");
core.setAccessService("xxx.access");
core.setConfigService("xxx.config");
/*
* start message transport, using rpc-polling
*/
core.startMessageTransport({
mode : "poll",
transport : "rpc",
service : "logbuch.message",
interval : 10,
authenticated : true,
stopOnError : false
});
....
Then, in your application, you use "modules" which should have access only
to its sandbox, and no access to the core API and - theoretically - to no
other "dangerous" API (which is currently unenforceable). The module have an
init() method which stores the sandbox instance in a private member var:
init : function(sandbox){
this.__sandbox = sandbox;
}
and then you pass a sandbox to the module like so:
myModule.init( new qcl.application.Sandbox() );
The sandbox then has an API which is close to the Core's API, minus the
"dangerous" methods.
As said, at the moment this is a bit theoretical, since it is almost
impossible to keep any third-party code from accessing whatever it wants, be
it DOM, I/O, qx - it's all in the global namespace. But it could become more
interesting once ECMAScript 5.0 Strict Mode becomes more used and also gets
integrated into the qooxdoo way of coding.
Best,
C.
--
View this message in context:
http://qooxdoo.678.n2.nabble.com/qcl-access-demo-application-tp6295025p6342454.html
Sent from the qooxdoo mailing list archive at Nabble.com.
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
