View Full Version : Cmd simply does not work, and Ext.Loader not getting disabled!

14 Dec 2012, 8:23 AM
Got some built JS for the shell of an application (really, it does little so far), am referencing it in a html file, and then loading the web page.
This gives Ext.Loader 404 errors.

Point one, which worries me greatly, is the fact that the compiler has missed some classes, Ext.data.NodeInterface & Ext.layout.container.Column in this case.

Point two is the fact that the dynamic loader should be disabled in all-classes.js, and this does not appear to be the case.

I'm concerned.
The SDK worked, I have seen it work, and have confidence in it.
Cmd, as far as I can see so far, does not work.

I may have to cross-post this, since there's obviously no-one here...

14 Dec 2012, 8:29 AM
Ahh, I have an inkling why point one has arisen - due to my FrameworkFixes.js; will look into it and report back.

Point two stands though.

14 Dec 2012, 8:39 AM
Ok, thought I had it, but nope.

It clicked that I include some JS for overriding broken parts of the framework in a JS file, using:

document.write('<script type="text/javascript" src="' + Clients.CompanyName.ProductName.Constants.altusRoot + '/app/FrameworkFixes.js"></script>');

And part of this FrameworkFixes.js contains (amongst other things):

function() {
Ext.override(Ext.data.NodeInterface, {
statics: {
* Fix to reset childNodes to [] rather than null.
* This is still needed as of 4.1.3.
* See: http://www.sencha.com/forum/showthread.php?203853-TreeStore-bugs-appendChild()-load()
decorate: function(modelClass) {

// Replacing implementation of destroy, supplied from getPrototypeBody.
* Destroys the node.
destroy : function(silent) {
* Silent is to be used in a number of cases
* 1) When setRoot is called.
* 2) When destroy on the tree is called
* 3) For destroying child nodes on a node
var me = this,
options = me.destroyOptions,
nodes = me.childNodes,
nLen = nodes.length,

if (silent === true) {

for (n = 0; n < nLen; n++) {

me.childNodes = []; // <WestyFix> This was getting set to null.
delete me.destroyOptions;
} else {
me.destroyOptions = silent;
// overridden method will be called, since remove will end up calling destroy(true);

function() {
Ext.override(Ext.layout.container.Column, {
* Required to prevent scrollbars showing unncessarily in IE7.
* Reported here:
* http://www.sencha.com/forum/showthread.php?231065-4.1.0-Calculated-height-of-window-is-wrong-when-using-column-layout-in-IE7&p=856433
calculateHeights: function (ownerContext) {
var me = this,
items = ownerContext.childItems,
len = items.length,
blocked, i, itemContext,

// in order for innerCt to have the proper height, all the items must have height
// correct in the DOM...
blocked = false;
for (i = 0; i < len; ++i) {
itemContext = items[i];

if (!itemContext.hasDomProp('height')) {
itemContext.domBlock(me, 'height');
blocked = true;

if (!blocked) {
// SEM: In some IE rendering modes, the height of the innerCt is incorrect but the 'outer' element is correct
if (Ext.isIE6 || Ext.isIE7 || Ext.isIEQuirks) {
height = me.innerCt.dom.parentElement.offsetHeight;
} else {
height = me.innerCt.getHeight();
// SEM

ownerContext.setContentHeight(height + ownerContext.targetContext.getPaddingInfo().height);

return !blocked;

Now, since the Cmd no longer actually loads the site into phantomjs this loading will not get spotted.
So, I added the following to my index.html:

<script src="Altus/app/FrameworkFixes.js"></script>

But nope, is still trying to dynamically load those files, so point one stands.

As an aside, is there an alternative to Ext.requires I could be using in FrameworkFixes, something like Ext.ifLoaded("className", function() { ...})?


14 Dec 2012, 8:51 AM
Tried Ext.Loader.loadScript - still gets missed by Cmd.

16 Dec 2012, 7:46 PM
AFAIK if you use the following format:

Ext.define('myapp.Ext.data.NodeInterface', {
override: 'Ext.data.NodeInterface',


Ext will only apply the override if the overridden class ( 'Ext.data.NodeInterface' ) is actually loaded/required somewhere in your code.

17 Dec 2012, 1:10 AM
Yeah I think you're right, thanks.

I guess I'll have to update my overrides to the 'new' style - I put it off when the change happened...