I've been struggling trying to strike the right balance between reusability and complexity when it comes to organizing my Backbone objects into AMD's (for medium- to large-scale applications)
(A) Should every Backbone object (models, views, etc) be in their own module?
(B) Should related Backbone objects be in the same AMD module? (ie: PersonModel, PersonCollection, PersonView objects in the same module definition)
Option (A) seems to allow the most flexibility and reusability, but also the most complexity because of the (potentially) high number of files. While option (B) may make it easier to manage things, but less flexible and really difficult to unit test.
How is (or has) everyone else structured these things?
I good thing about requirejs is that it allow you to abstract the physical files into structured namespaces. You can take the approach (A) and create each backbone class in their own file, then create a "namespace" module to glue all the related classes together.
// Suppose you have PersonView.js, PersonCollectionjs, PersonModel.js as modules
// create a Person module to function as namespace
define(["PersonModel", "PersonCollection", "PersonView"], function(model, collection, view) {
return {
Model: model,
Collection: collection,
View: view
};
});
This keep the modules organized in their own files and gives you some flexibility to write one module per class without requiring you to expose this organization for the rest of the application (I really don't like to have to write require("PersonView", "PersonModel" ... ) every time I need to use the person's objects, it's easier and cleaner for consumers to declare a dependency on a "namespace" instead of independent classes).
For medium to large backbone projects I prefer to use requirejs with a separate module for every model, collection, and view. I also use the "Text" plugin for requirejs so I can load underscore templates just as I would any other module. This for me seems to be the sanest way to manage a large project and I have never really felt overwhelmed with the number of files I have.
+1 on using the requirejs optimizer when pushing your app to production. Works really well.
http://requirejs.org/docs/optimization.html
I just released an open source toolkit which will hopefully help others as much as it helps me. It is a composition of many open source tools which gives you a working requirejs backbone app out of the box.
It provides single commands to run: dev web server, jasmine single browser test runner, jasmine js-test-driver multi browser test runner, and concatenization/minification for JavaScript and CSS. It also outputs an unminified version of your app for production debugging, precompiles your handlebar templates, and supports internationalization.
No setup is required. It just works.
http://github.com/davidjnelson...
Related
People mention requirejs together with marionette, backbonejs and the like.
requirejs seems an asset loader -- executing your rules on when to load what.
I know the first 'page' of my single-page-app already needs most of the files. If I don't mind loading all files in one go, can I simply ignore requirejs?
Technically yes. Only dependencies for marionette-backbone are
jQuery v1.8+
Underscore v1.4.4 - 1.6.0
Backbone v1.0.0 - 1.1.2 are preferred
Backbone.Wreqr (Comes automatically with the bundled build)
Backbone.BabySitter(Comes automatically with the bundled build)
Further require.js can manage use code structure in a manner which give your code much resource efficient code at the end. From my point of view for simple application which you need simple set of views,models and collection with manageable amount of code it ok to proceed without require.js.
But if your application have complex logic and higher number of resources it's good to go require.js. Because it not good to send 15+ like individual resource requests server at very beginning of your application load. Require can make any number of your resource in to one server resource. That's the advantage.
What I prefer is one request of all css, one for all js, one for sprite image for graphic if things are big to handle which allow to create fast performing application.
Take you decision looking at the amount of resources of the project. It's not essential have require.js form the beginning of your application development.
I'm trying to set up a large angular web app, with an architecture as described here
What I can't get my head around is how to make modules completely independent from other modules. All github boilerplate's or example projects which focus on modules all seem to have modules which heavily depend on common modules or functions/services. That would sort of defy the purpose of keeping everything separate doesn't it?
Take the following two example:
I have a utilities module which handles some basic functions (hashes etc.), and another module which handles all communication with an API. Imagine a User module which needs to make hashes and communicate with the API, how do I handle that? Directly injecting the Util and API modules as dependencies would break the in dependability, and putting them into the User module as well would mean a lot of double code (imagine multiple modules using the Util and API modules). Or should I use the mediator to mediate the communication?
User information which is stores in the User module is something that should be used almost application wide, and in the facade as well for example (the facade should handle security according to the article). How can I allow all of the application to access the information, without everything being dependent?
Thanks in advance :)
I answered a similar question here.
You are on the right track with separating behaviors into modules.
The idea is to embrace Dependency Injection as a means of collecting these behaviors into a rolled up module. With an IoC container at your disposal you can exercise discipline in your naming and other conventions to keep your app loosely coupled through configurable components.
We have a general app type module that simply registers the appropriate feature modules. That is in turn bootstrapped by a boot module that simply calls angular.bootstrap(['app']) somewhere (ours is in the page).
We can easily decorate or replace existing services/controllers/whatever with this setup and teams can work in isolation while features scale at different rates.
For example:
var myWidget = angular.module('myWidget',[])
myWidget.directive('myWidget',function(){...})
myWidget.factory('somethingImportant',function(){...})
var myDomainModel = angular.module('myDomain',[])
myDomainModel.factory('someModel',function(){...})
... //more models
var app = angular.module('app',['myWidget','myDomain'])
app.factory('applicationWidePolicyHere',function(){...})
//on index.html; das boot.
(function(){ angular.bootstrap(document,['app']) })()
I've noticed some people define a new module for each controller, service, directive etc.
angular.module('controllers.Dashboard',[]).controller(...);
angular.module('controllers.Details',[]).controller(...);
angular.module('controllers.List',[]).controller(...);
However, isn't that a performance issue? I mean: for each controller you create, you also create a new module.
What do you think?
Any performance hit would be incredibly minimal. What you do gain in terms of performance though, is testing speed. Testing can be localized to small modules that don't need to load in the entire application to perform what they need to.
On the code organization side, I personally like the idea of breaking up modules depending on feature not architectural slice. So instead of having a module for controllers, a module for services, etc, create a new module for every new feature/piece of the application. This way you can group together conceptually related controllers, views, services, filters, and so on.
The overhead will be minimal in practice. It is really more of a code organization type issue. On my project we have a FooService, FooController,FooDirectives, BarService...
I'm currently learning ExtJs, but I can't seem to grasp my mind arround the following.
What is the difference between the array notation and the requires notation
For example:
view['MyPanel']
model['MyModel']
controller['MyController']
store['MyStore']
requires: ['namespace.view.MyPanel']
Do they do the same or ... ?
And why do I have to put ALL the views, models, controllers and stores used in the application inmediatley in the app.js?
Can someone clear those thing out to me? :)
Requires will just load the files matching the class name from the server. It will not instantiate anything. You should require what is needed in each view/controller/model, you don't need to have it all in app.js.
For instance, if you have a MyModel that has a relation to MySubModel, then MyModel would require MySubModel. Requires is essentially about loading other classes when needed so that they are fetched from the server before being used - since using a class when it is not loaded creates a noticable delay due to ExtJS having to fetch the class from the server before instantiating it.
The models, views and controllers arrays in a controller are a convinient way to require such resources as you don't have to specify the path to the models/controllers/views folders. See the docs on controller models config for example.
A guide on how to structure your application is available here even though I don't really like that they load all views and all controllers in this approach. But it's a good start. You can dynamically load stuff later on when your application grows.
I need to create plugins that hook into the functionality of my main application. CakePHP plugins only instantiate themselves when its own controller is called meaning I cannot affect the processes of my main application.
mainapp/action2baffected
myplugin/
I like the idea of having self contained pluggable models , is there any other way to get this to work? Creating models on the fly etc or write a plugin system from scratch with no cakeiness!
You can use components and behaviors (from the plugins) into your core application. There is one very good presentation of Pierre MARTIN Using reusing-plugins. It's a really inspirational resource.
We have put quite a lot of work into making plugins truly self contained in Infinitas
You can have a look at some of the methods that are used, but the main code is in the events. Everything from cache configs, db connections and include assets like css/js are done from within the plugin, even injecting some markup into views is handled.