Framework Structure
By Matt. Filed in Technology |
When building a framework, it”s critical to get the structure correct from the outset, else it”ll just make things far more complicated in future. As I”m familiar with the Zend Framework, and it seems to have a fairly logical structure, I based the JS framework structure around this.
Fundamentally, the framework has several key components:
- HTML entry page
- Initial script
- MooTools – Core and More
- Custom MooTools extension code
- Loader
- Bootstrap
- Library code
- Application code
HTML Entry Page
This is the page that users will visit. It is incredibly lightweight. All it contains is the doctype (XHTML 1.1), enough markup to make the page valid, and a script tag pointing to the Initial Script.
Initial Script
The job of this script is to load in the MooTools library code, our custom extensions to it, and then the autoloader. Before it does this, it can do some context switching based on query string parameters to load the page in a development environment. It is also used to initialise some global variables that will be needed later.
MooTools
Exactly as the title suggests, this is the MooTools Core and More libraries. Depending on the environment, the Initial Script will either load uncompressed versions of core and more separately, or a pre-minified file containing both Core and More.
Custom MooTools Extension Code
As great as MooTools is, there was quite a lot we had to add in here to give us the functionality we needed. I”ll discuss this in more detail later, but this included things like custom Mutators, the ability to write abstract methods, and helpful shortcut methods.
Loader
This is where a lot of the magic behind the framework lies. I borrowed a lot of this from Dojo”s way of doing it, and it has resulted in an extremely powerful OO system. The loading system is responsible for loading in all JavaScript, CSS and HTML resources that the framework requires.
We used a naming system whereby an underscore in a class name corresponds to a / in a filepath. This very simple system is incredibly effective and allows convenient namespacing of files. I won”t go into it any more at this point, other than to say that getting the loader right was the crux of the entire framework.
Bootstrap
Now that MooTools, our custom MooTools code, and the loader are now all available, the bootstrapping can commence. Essentially, this is responsible for loading in the config, setting up the log writers, and initialising the application.
Library Code
As with any OO project, the key is good abstraction of code. The obvious way of doing this is to have a library set of code that is generic enough to be used throughout. For example, there is a class that acts as the base Model class, and is extended elsewhere to create specific models. The JSON-RPC client also exists in the library code.
Application Code
Within an ./application/ folder, each application in the framework has its own subfolder, containing all the code relevant to that application. You should try not to place any dependencies between these applications, and instead, always try to extend from the library code.