Blast Mojo Overview
- 1. The Blast Mojo Framework Loyal Chow | Technical Experience Director
- 2. What is Blast Mojo? Blast Mojo is a patterns-based JavaScript framework that provides a consistent event- driven architecture for complex client-side web applications, built on existing best-of- breed JS libraries. Its objectives are to provide a structured way of developing Rich Internet Applications, abstract complexities by separation of concerns, and maximize re-use of existing code, in order to maintain knowledge and improve on speed and quality of deliverables.
- 3. Why create another Framework? In 2005-2006, we discovered that: The JS landscape was constantly changing, and there was no clear standard Different developers liked different libraries such as jQuery, Prototype, MooTools, Dojo and YUI, causing large amounts of developer ramp-up between projects as code was written differently Each project team applied their own structure tied to their own uses of a particular library. As the code-base grew, this eliminated the initial savings of using these libraries as the code eventually became so customized, under-documented, and complex that it became difficult to read, manage and maintain Code became tightly integrated, making it difficult to develop in parallel and debug without impacting someone or something With a lack of consistency across JavaScript projects, code written on one project was not re-usable in another, causing us to rebuild the same components again
- 4. Why create another Framework? So in early 2007, Blast Mojo was born in order to: Provide a standard, consistent architecture for developing with JavaScript Work with different libraries without conflict Structure and organize JavaScript Enforce separation of concerns Ensure code can be shared and re-used
- 5. Why use Blast Mojo? Key Benefits Blast Mojo offers a foundation that other libraries and developers can take advantage of. It was built to provide a consistent architectural structure for development of small to massive projects allowing for code reuse and flexibility Enforces organization and clean separation of code to ease readability and maintainability Includes Mojo StdLib library which consists of well-tested and reusable behaviors and components for rapid prototyping and development Increases productivity of large teams working in parallel, particularly on Agile projects, by dividing work into implementation silos and allowing incremental development Reduces developer ramp-up time starting on new projects because they are already accustomed to the coding structures, patterns and practices Development speeds up as times goes on compared to the opposite that happens when code becomes too tightly bound
- 6. Why use Blast Mojo? Core Philosophies Readability is paramount. It is more important to have readable code than less lines of code Cover the fundamentals. Keep it simple, keep it generic – include a small set of tools that can be used in many ways Build good separation from the beginning. Implementation silos, clearly separated, maximize refactorability Add just what is needed. Evolution is driven 100% by real-world project requirements Don't try to do too much, and don't repeat yourself (DRY). Stand on the shoulders of others Better Debugging = Faster Development
- 7. How does Blast Mojo work? Components
- 8. How does Blast Mojo work? Sample Data Flow
- 9. How does Blast Mojo work? Components: SiteMap HTML code has no knowledge of any JavaScript Page functionality is stored in Controllers which are “mapped” to DOM elements via a SiteMap configuration file Blast Mojo automatically injects Controller dependencies into the HTML code as needed at run-time This form of Dependency Injection ensures JS and HTML are completely de-coupled, and allows code to be easily added or removed
- 10. How does Blast Mojo work? Components: Controllers Controllers are event-driven and observer-based Wire everything together in Mojo Decouples all event handling from markup (no inline JS in HTML) Allows attaching observers to any object, function, or via CSS selectors Observers delegate to a command or behavior action Encourages developing applications by building upon fine-grained commands that are chained together (maximizing reusability) Are automatically mapped to page components via the Mojo SiteMap, and avoid ID collisions by maintaining a scoped DOM context Allows AOP-style interceptions of commands for code injection
- 11. How does Blast Mojo work? Components: Command Types event process data (async / sync) event UI reaction event condition action Command Behavior Rule
- 12. How does Blast Mojo work? Components: Service Layer The Service layer consists of a Service Locator and a collection of Service Delegates. The Service Locator provides a single central point to manage all services, and abstracts each service into a lookup ID, decoupling it from its specific details The Service Delegate acts as an Ajax proxy, and provides additional helper functionality: handle service-level exceptions, normalize errors transparently perform retry and failure recovery perform client-side caching of results automatically map http methods based on abstract service name instantiate JSON data objects
- 13. How does Blast Mojo work? Components: Model & Data Binding One of the key benefits of RIAs, compared to traditional web applications, is that the client is stateful. Mojo keeps state on the client with the Mojo Model, providing a storage interface to manage state data, and abstracts data into keys with semantic meaning. Data stored can be strings to complex objects. Mojo comes with a client-side templating component called Mojo Template, which registers to a Model source, and automatically data binds when the model is updated. This greatly simplifies development, and ensures that presentation stays decoupled from functional code.
Editor's Notes
- #2: 11/15/09 06:53
- #4: Each developer has their own history, opinions and preferences in utilizing a varied number of JavaScript libraries such as jQuery, Prototype, MooTools, Dojo and YUI. To any developer and their team, the cost of utilizing these libraries were seen as a means to save developer hours, allow development to react to creative needs and stabilize estimation due to each libraries centralized, tested code base, good API and strong communities. What we noticed within our team environments were other incurred costs that ended up eliminating the savings of the use of these libraries. We found that the foundation, the blue print that would drive the structure of the interface would be specifically tied to one or two individuals thinking. This thinking required a number of hours to ramp-up any new developers to the project(s), the code eventually became so customized, under documented and complex that we were left with little or no reuse and no take away from the project. We were leaving the client with a code base that would require another rewrite when the next refresh was to take place. In short, we found ourselves building the same systems from the bottom up each and every time using a number of 3 rd party libraries. What we needed was a good stable starting point. 11/15/09 06:53