[eluser]esra[/eluser]
There is a document on the EXT JS site that describes the loading order of various files. For some silly reason, this document is referenced on the page where custom ext_all files can be generated and some of the older 1.1 documentation pages. One of the fundamental concepts of AJAX-like technology is the use of a base set of CSS ids with corresponding Javascript functions. Thus, javascript code for both the EXT base and the all classes are dependent on the CSS ids defined in the base css file. Similarly, the base javascript file includes utility support for Observable and other utilities which are used (are in the class hierarchy) of many EXT JS widgets and other code. Thus ext_all is dependent on the base utilities.
A similar problem can happen with examples.js when you use the example code as the basis for your own code. I use examples.js as the basis for a common.js file which is stored above the extjs directory. Examples.js includes some basic code required to handle the window state files which are stored under examples/states/. That is, the states files are dependent on code in examples.js. Since I usually strip out the examples directory from my final distributions, I moved the examples/states/ javascript files and the common.js file (example.js) to a directory above extjs to ensure they are always available to my templates. You only need to do this if you remove the examples directory from your extjs directory for reduce library size and also need to manage window states (which appears to be so because you are using layout.js).
The various inheiritance diagrams included in the EXTJS API documentation help a lot when isolating problems like this because they show dependencies. A utility function such as Observable in EXTJS is akin to a helper in CodeIgniter.