JavaScriptMVC is designed to be interdependent with other popular libraries, such as jQuery and Prototype. This guide will show you how to use JavaScriptMVC with other libraries and keep your application lightweight with no duplicated functionality.
To use another jQuery or Prototype in conjunction with JavaScriptMVC:
1. Include the other library first, before any JavaScriptMVC plugins.
include.resources('prototype');
include.plugins('ajax','view');
2. Use the library as you normally would.
// using Prototype functionality,
// which has replaced similar JavaScriptMVC functionality
Ajax.Request(...);
Element.insert(...);
Behind the scenes, JavaScriptMVC's plugin system is designed to replace its own low level plugins (Element, Ajax, Event, and Helpers) with the equivalent jQuery and Prototype functionality. This way, duplicate functionality isn't loaded. For this to happen correctly, Prototype and jQuery must be loaded first, before any JavaScriptMVC plugins.
When JavaScriptMVC functionality is replaced by another library, the JavaScriptMVC API wraps it. For example, using Prototype, Prototype's Ajax object is accessible ad you'd expect, and MVC.Ajax is now simply a wrapper API around the Prototype Ajax object. This way, you can write your applications once and they'll work the same if you swap out the underlying library.
Everything works generally as you'd expect. JavaScriptMVC doesn't overwrite any objects or classes defined by jQuery or Prototype. Any of their basic type extensions (String, Array, Object, or Function) are used in place of JavaScriptMVC's. In a few cases (Prototype's camelize is one example) their basic type extensions operate differently than JavaScriptMVC's, so keep that in mind.
For other libraries, use no_conflict mode to prevent any naming conflicts. There is no built in support for replacing functionality for libraries other than jQuery and Prototype. Here is how you turn it on:
include.resources('mootools');
include.plugins('ajax','view');
MVC.no_conflict();
In no_conflict mode, any JavaScriptMVC objects that were previously available through the global window object (Ajax, View) are now wrapped in the MVC object (MVC.Ajax, MVC.View) in order to prevent collisions. Additionally, JavaScriptMVC's basic type extensions, which are normally available to instances of each basic type, are only available as class methods of MVC.String, MVC.Object, MVC.Array, and MVC.Function, to avoid overwriting any basic type extensions added by other libraries. Here is an example:
// not available in no_conflict mode
'oneTwo'.camelize();
// always acccessible
MVC.String.camelize('oneTwo');
No_conflict mode ensures no functionality will be overwritten due to naming conflicts. It's worth noting that JavaScriptMVC's no_conflict is very different from jQuery's. In jQuery's normal mode, all functionality is always wrapped in some global object, usually $ or jquery. JavaScriptMVC's normal mode exposes objects through the global window, which is easier for developers.