CODEWITHSUNDEEP
javascripttemplatesbackbone.jshandlebars.js
user1834464
user1834464

Reputation:

Should all the view logic go in templates?

For example, I need to disable every input when the view's model isn't new (has an id).

I can do :

if(!view.model.isNew()) { view.$('input, select, textarea').prop('disabled', true); }

or I can go do an "if" on every input I have in my template:

<input type="text" {{# if model.id }}disabled{{/ if }}/>

If we follow the MVC (or MVP) pattern, I guess the second approach would be best, since the view logic is in the view. However, if I go with this approach and decide to change the condition that disables the inputs, I need to change it for every input in EVERY template. If I leave in the JS code, there is only one place to change.

This is just one example, but I am having similar dilemmas with alot of things. Hopefully you got an answer for that.

Cheers!

Upvotes: 1

Views: 244

Answers (3)

Marc Greenstock
Marc Greenstock

Reputation: 11668

Perhaps what you might be looking for presenter (aka decorator).

Instead of sending the template the model directly, consider sending it though a presenter, this way you can construct the attributes for the input field. Something like this:

present = function(model) {
  return {
    inputAttributes: model.isNew() ? 'disabled' : '',
    id: model.id,
    name: 'Foobar'
  }
}

template(present(model));

then in your template:

<input type="text" {{inputAttributes}}>

Upvotes: 0

Michael.Lumley
Michael.Lumley

Reputation: 2385

Based on your question, I'd say that you're probably running into this general problem for two related reasons -

  1. You're using backbone exclusively, rather than a framework like Marionette or Chaplin.
  2. Your views are "too big" and trying to incorporate too much material into a single view.

I almost never include logic into templates and that's because I almost never need to. That's because I write a lot of very small views, and piece them together to make large views. Marionette's view classes make this very easy to do, by subclassing the backbone view into different view types, adding additional utilities and drastically cutting down on boilerplate. Marionette is also very good at handling nested views, which really allow you to drill down and create the exact view tool you need for a specific use case.

It's not at all uncommon to be able to define a useful view using Marionette in 1-2 lines of code, which gives you a lot of flexibility to make very small, efficient views. The disadvantage to making lots of small views is that it's a lot of code to write, and could become difficult to maintain, but Marionette makes that disadvantage relatively insignificant. Marionette only took me a couple of days to get the hang of, and I highly recommend integrating it into your Backbone apps for exactly this problem.

When your views are big, and try to do too much, you wind up with the problem you're describing - you have to modify them too much to fit your specific needs and your code gets ugly and hard to read. When you have a lot of small views, they're very responsive and need little if any customization.

The example from your question is, I think, a border line case. My gut instinct would be to create two entirely separate views and run them under the following pseudo code:

editableView = { //definition }}
disabledView = { //definition }}

if (newModel)
    editableView.render()
else
    disabledView.render()

This is my gut instinct because my bet is that there are other differences between the views than whether the inputs are editable. Even if there aren't now, you may find in a few months that your needs have changed and that you'd like to incorporate some changes. The approach I suggest allows you to put those changes right into the appropriate View and not have to worry about logicking them out in a single view and deciding whether that logic belongs in the template or the view.

If you were absolutely certain that the only difference between the two views was going to be whether the inputs were editable, and that your needs are not going to change in the future, then maybe you would want to think about rendering them with the same view. If that is the case, I'd recommend that you put the logic in the javascript, rather than in the template, for the reasons you identified. But as I said, your example really is a borderline case, and in most instances I think you'll find that shrinking your view scope will really help you to see where your "template logic" belongs.

NOTE: I've talked a lot about Marionette in this answer, but I also mentioned Chaplin as another option above. I don't have much experience with Chaplin, but you may want to consider it at it as a Marionette alternative.

Upvotes: 1

Nima Shahri
Nima Shahri

Reputation: 177

I prefer to do implement view logic in templates:

  1. It is easier to change and read
  2. Any dependency to id, element and etc can be implemented in template
  3. List item
  4. complex logic can be implemented in templateHelper of marionette or serializeData of Backbone without any dependencies to content of template or view
  5. you can also implement complex logic using Handlebar Helper

Disadvantages of view logic in code are:

  1. in case of changes to selectors (id, classes and so), all views have to be changed or reviewed
  2. logic has to be applied again if view is re-rendered

Upvotes: 0

Related Questions