Best Way to Organize an ExtJS Project

Question

I've just started developing an ExtJS application that I plan to support with a very lightweight JSON PHP service. Other than that, it will be standalone. My question is, what is the best way to organize the files and classes that will inevitably come into existence? Anyone have any experience with large ExtJS projects (several thousand lines).

Answer 1

While developing your application your file and folder structure shouldn't really matter as you're probably going to want to minimize the release code and stick it in a single JS file when you're done. An automated handler or build script is probably going to be the best bet for this (see http://extjs.com/forum/showthread.php?t=44158).

That said, I've read somewhere on the ExtJS forums that a single file per class is advisable, and I can attest to that from my own experience.

Answer 2

I would start here http://blog.extjs.eu/know-how/writing-a-big-application-in-ext/

This site gives a good introductory overview of how to structure your application.

We are currently using these ideas in two of our ASP.NET MVC / ExtJS applications.

Answer 3

When starting new big project, I decided to make it modular. Usually, in big projects not all modules are used by a particular user, so I load them on demand. F.e., if a project would have 50+ modules, the big probability is that user is working only with 10-.

Such architecture lets you to have the initial code relatively small.

Modules are stored on the server and loaded by AJAX call, eval'uating the responseText in AJAX callback. The only issue with this, you must keep track on module dependencies, which could be stored inside modules as well. I have a class called Module, and I check every new module instance for existance within the task. If it doesn't yet exist, I load it from the server.

Answer 4

I suggest users are willing to wait for an application to load, so we typically load all of JS during initial app startup. I suggest loading and eval'ing JS files as needed is unnecessary - especially when all JS will be minified before deployment to production.

I suggest namepsaces, one class per file, and a well-defined and well-documented class hierarchy.