The FED (Front End Development) Process framework takes advantage of the object oriented design approach from MooTools and applies it to the entire scope of front end development.
Using the file structure and build tools provided with the download, you will be able to start building webpages very quickly and efficiently. FED Process is also built to be highly maintainable so that even if you have many pages, you would still be able to locate your JavaScript or CSS resources easily.
NEW (2011/AUG/15) - 1.3.1 supports MooTools 1.3, has a bunch of fixes and bundled with new LazyLoader.
Traditionally, web developers would include every JavaScript files with script tags or they would write all their code into a single large JavaScript file. However, developing with this pattern often result in hard to read spaghetti code especially if they do not follow an object oriented approach.
With MooTools' object oriented approach however, the framework empowers code separation. That means you can easily break classes into its own files for a much better decoupling of functionality/widget. By applying a good code design, a loosely coupled MooTools class allows your code to be a lot more re-usable. Furthermore, you can package them easier and release them onto the Forge. The only problem is that including each of these classes in its own script tag could cause some performance issues on the front end. Primarily, there would be unnecessary http request for files.
Using a build process, we can keep our code separated while at the same time, packaging all these files into a single script.js would remedy the issue of having the page to make too many http requests. With the FED Process's approach, we've been able to achieve a high re-usability rate of our widgets and a great compression scheme using a minifier such as the YUI Compressor in conjunction of a server-side compressor such as GZIP.
Now the way you would work with this FED Process framework is as follows: You code your html as you would, however, the body id is key. Each page requires a unique body id to enable page-specific JavaScript. The body id tells the process which Page class to run. So for example, on your homepage, you would use a body id of "hom", the process would automatically look for Page.Hom.js which extends Page.js and would execute ONLY the code inside of Page.Hom.js. This allows your code to be very clean and efficient in the sense that other pages' class would not execute. Now inside of your Page.Hom.js, you will instantiate all the widgets classes that you need. So let's say you want to run a lightbox widget on the homepage only, then you would instantiate lightbox inside of Page.Hom.js.
Following such a process would make your life much easier in the long run when your site starts to get heavy on functionality. Another advantage is that it will allow for a friendly and painless multi-collaborator environment. When using SVN or GIT, we almost never run into code conflicts because all the files are so clearly separated. Since the code is built into the /b (build) folder, the build process actually cleans out the /b folder every time. So any conflict in the b/ folder can be ignored.
In some of our test cases and actual production work, we have more than 9000 lines of code without a single conflict when using this process. We believe that releasing our FED Process will help MooTools developers to take advantage of the object oriented nature of MooTools while adding Forge plug-ins into their own projects would be effortless. This is a tried and true development process that is stable and used everyday within our team. If you have any suggestions, then please feel free to let us know at david.chan@reol.com
This will seem like overkill at first, but contributes to the maintainability of the process.
/Source
/pages: Your static html pages lives here
/resources: JavaScript, CSS and images
/bin: YUI Compressor lives here
/main: This is your module, feel free to add more
/build.xml: This tells ANT how to build your resources, per module basis.
/c: CSS Folder
/n: Non Minified CSS source
/b: Built source
/widgets: Contains CSS classes that represent a widget
disclaimer.css: Legal mumbo-jumbo
global.css: Globally used CSS classes such as .clear
ie.css: All IE specific CSS rules
ie7.css: Only for IE7
layout.css: CSS classes for main layout elements
pages.css: Page specific CSS classes
/y: Minified CSS source
/b: Built and minified source
/i: Images Folder
/l: contains layout specific images
/p: contains page specific images
/body-id: contains a single page specific images
/w: contains re-usable widget specific images
/j: JavaScript Folder
/b: Built source
/core: Utility and System classes
/widgets: Functionality classes
/ext: Externally loaded classes
/mixins: Implementable classes
/native: Extended Native classes
/tp: Third party classes
disclaimer.js: Legal mumbo-jumbo
global.js: Global variables
global.dev.js: Global variables for your local development environment
main.js: Entry point of your JS application
Do not ever develop under any b/ folder. Running an ANT build would result in complete overwrite of the b/ folders. Note that any changes to JavaScript or CSS resources require an ANT build, this should become second nature.
A website is being build for this front end framework. Look for it in the coming months.
We will soon add in more demo test cases to better illustrate the process.
Even though the current version is stable, we strive for continuous improvements to our standards and processes. If you have any suggestions, please feel free to let us know at david.chan@reol.com
A note on comments here: These comments are moderated. No comments will show up until they are approved. Comments that are not productive (i.e. inflammatory, rude, etc) will not be approved.
Found a bug in this plugin? Please report it this repository's Github Issues.
blog comments powered by Disqus