View spec.

view.md

View

View(model, el, options)

The View's constructor should take an optional model. It should also take an optional el so that the user can use a pre-made element instead of the View creating its own. If necessary, it should take additional options as a dictionary.

For convenience, add an el -> options overload if you add an options argument.

View.template

The View's template should live at .template if one exists so that it can be overriden if need be. The HTML for the view's template is also part of it's spec, so it should be well thought out. Use namespaced class names for child elements to avoid collisions (for example an .integration element's label would be .integration-label).

#model

The view's model property is a reference to its model. The model can be either a plain Javascript object, a model with ATTR getter/setter methods like component/model or a model with get and set methods like backbone models.

It's tempting to attach the model to it's named property (for example an IntegrationView's model would live at .integration) but those aren't spec'ed so no one else but you can know they exist.

To accomodate all types of model the user might want to use, the view should handle getting and setting the model in a few different ways:

• plain object (ie. model.name = 'bob';)
• getter/setter method (ie. model.name('bob');)
• get/set methods (ie. model.set('name', 'bob');)

That way the user is free to use whichever model makes sense for their project. For an easy way to accomodate this, checkout ianstormtaylor/get and ianstormtaylor/set.

#el

The view's el property should be a reference to its DOM element. It should not be a jQuery or dom object. If your view does a lot of DOM manipulation and you need a shortcut, use .$el, but that is private and others shouldn't assume it exists.

#addClass + #removeClass

These methods should be present to let users customize your view with their own use-case-specific class names.

#emit #on + #off

Events. The easiest way to support this is to just mixin component/emitter.

I have a idea, a component with render . login.render

example

var LoginComp =  require("login"),
     login1 = new LoginComp(),
     login2 = new LoginComp(),

     render1 = require("login.render"),
     render2 = require("./selfRender");

login1.bindRender(render1);
login2.bindRender(render2);

// then login1 and login2 have different rendering .