Question

Im using Sproutcore and Rails and wonder where to put strings like attribute slugs and comments.

In the model layer I have some model classes eg.

SC.User = SC.Record.extend({

  firstName: '',

})

Should I put the attribute slugs and comments here in the model classes:

SC.User = SC.Record.extend({

  firstName: '',
  firstNameSlug: 'First name',
  firstNameComment: 'Enter your first name',

})

Or should these be in the views decoupled from the models?

The benefit of having the in the model classes is that I now can have a generic view that iterates all model attributes and shows them automatically.

What do you think?

Answer 1

Sproutcore is based on the model-view-controller paradigm, moreover it uses a rather conservative strict version of mvc. Your model should only contain the real values of a certain domain object. Hence, you shoudn’t place your comment and placeholder strings within your model-object.

Instead use your controller to bind to your model object as well as to all additional properties you want to discouple from your view. A typical controller setup might look as follows

YourApp.userController = SC.ObjectController.extends({
    user: SC.User.create({ ... }), // Create a new user or load one from the store
    firstNamePlaceholder: 'First name',
    firstNameComment: 'Enter your first name',
    ...
});

It might make sense to combine the additional properties within a controller in one or more objects defined inside the controller to do some grouping, e.g.

YourApp.userController = SC.ObjectController.extends({
    user: SC.User.create(),
    placeholder: SC.Object.create({
        firstName: 'First name',
        lastName:  'Last name',
    }),
    comment: SC.Object.create({
        firstName: 'Enter your first name',
        lastName: 'Enter your last name'
    })
});

This might lead to a cleaner structure in your views later on.

To put this in a nutshell, think of your model objects as traditional domain objects without class parameters use only parameters which are (potentially) unique to each instance of your domain object. Everything else goes into your controller layer. Make sure your views stay as dump as possible and only include bindings to all required application states.