Sencha Cmd should support sandboxed packages

[thorben]

Is it possible to use Sencha Cmd with a sandboxed build of Ext JS (e.g. ext-all-sandbox-dev.js)? I'm using Sencha Cmd 3.0.0.190.

I think a config option like jsduck's

--ext-namespaces=Ext,Ext4

would help us here. I'm mainly interested in a build of our custom classes, so it would be ok to have ext-all-sandbox.js included.

Is something like this going to be implemented or will I need to migrate my app to Ext JS 4 before using Cmd?

[dongryphon]

We have discussed sandbox mode and there are a couple or so directions it could go.

I am curious to know more specifically what you are wanting to achieve. I assume you have a mixture of v3 and v4 classes? Are you wanting to produce a subset of the frameworks? And wrap the v4 subset in a sandbox...

[thorben]

Yes, we've got a mixture of Ext 3 and Ext 4 classes. We are continually migrating to Ext 4, so the number of Ext 3 classes will eventually approach 0 .

What we want to achieve is a custom build of only the Ext 4 part of the app. In the final build, there will be 3 or 4 JS files

• Ext JS 3 Framework (ext-all.js)
• All our custom Ext JS 3 classes (this is generated using the current build process)
• Ext JS 4 Framework + Ext JS 4 custom classes (this should be the output of Sencha Cmd)

So Cmd wouldn't need to care about the Ext JS 3 classes and their proper inclusion, but only accept "Ext4" as the Ext JS 4 namespace.

I imagine this might just be a minor tweak to the tool, but maybe sandboxing is more complicated internally?

[dongryphon]

Cmd wouldn't need to care about the Ext JS 3 classes and their proper inclusion, but only accept "Ext4" as the Ext JS 4 namespace.

I imagine this might just be a minor tweak to the tool, but maybe sandboxing is more complicated internally?

Yeah that is the harder part - partitioning code that says one thing ("Ext") but needs to be understood as another ("Ext4") so that references from other code using the other name ("Ext4") link up properly. Then we need to wrap the sandbox around the Ext 4 code during the build.

It is all doable, but won't make in this release (3.0.0). Knowing that there are folks using/needing this support is really helpful though to decide when to pull the trigger on it.

I'm going to open this as a ticket so we can both track it.

Thanks for taking the time to explain what you were needing.

[dongryphon]

I have opened a ticket in our bug tracker.

[superstructor]

Any update on this issue ? Is it possible with the latest Sencha Cmd 3.1.2.342 release ? This is vital functionality for being able to port a legacy ExtJS 3.x application to ExtJS 4.x and a Sencha Cmd based build.

[medifirst]

Same problem : any update??

[Nick A.]

To get around this I ended up taking the sliced images from a non-sandboxed version of our theme that I generate and incorporate those images as the images for the sandboxed theme. When generating the theme with the sandbox I just use

sencha package build

from within the theme package and use the built <theme-name>-all.css.

The main downfall of this is that we can't take advantage of minimizing the js or css sent to the page as we use ext-all-sandbox.js and <theme-name>-all.css.

[adrianmirjan]

There are still issues with sandboxed mode in Sencha Cmd v4.0.1.45.
On sencha app refresh bootstrap.js still contains references to

Ext.Loader.addClassPathMappings
Ext.ClassManager.addNameAlternateMappings
Ext.ClassManager.addNameAliasMappings
Ext.setVersion

Loading the app gives the error

ReferenceError: Ext is not defined
Ext.Loader.addClassPathMappings({ bootstrap.js (line 7)

I'll try to mess around with refresh-impl.xml to fix it.
But I'd like this to be fixed properly.

[adrianmirjan]

Looks like sandboxed mode works differently. In dev mode you are still using normal mode, but building for production environment adds magic around your source code. This worked for me.