2

I was reading the excellent Getting started with ember.js post by @twbrandt recently and found his explanation of what your controller/view/model/router/template "should be responsible for" interesting.

When you have a database backed model all is well, put the persisted state in the model object and any state that isn't persisted will more than likely be found in the controller.

But imagine you allow your customers to define what a given model looks like (a configuration of sorts). From this configuration you need to scaffold out a "structure" to add these models at runtime.

For example, you allow your customers to define how many hours their business is open for each day. From this configuration you need to add an empty or "faux" model on the page to fill the entire day. You create these faux models because for each business day you also need to fetch the persisted versions of these (as the customer can actually create one using the app).

So using the config I'm left with a model (that actually gets saved to the database / etc) but I have a need to mix this w/ a model that doesn't really exist but in the handlebars template it really helps to have a shim 'd version of this so the html isn't complex (keeping the logic in javascript).

Currently I'm storing this logic on the model itself because of the "mix" between actual models that are persisted and the faux models / placeholders that get bound to the handlebars template as a single array (yet only some of them are usually persistence backed models).

My question is this -should this array be part of the controller as "some of it" isn't backed? Or should the entire array be an override of the ember-data's "find" method (as I'm doing it now) to enable the "replace each faux with a real model when it exists" behavior?

Thank you in advance

Toran Billups
  • 27,111
  • 40
  • 155
  • 268
  • Good question but it's a bit on the long side :) I think people will be more likely to answer it when you shorten it. – albertjan Feb 18 '13 at 22:22
  • I think it boils down to "where should I put an array of models / configuration (that acts as an empty model of sorts)". I see this used in software as a service web apps because they typically allow users to configure parts of the system that end up as models in memory (in the running application). – Toran Billups Feb 19 '13 at 00:44

1 Answers1

0

The view uses the controller to display data. The controller being a proxy to the model, the view can display information from the model.

But you don't have to link your template to the model. You can have properties on your controller that are used in your handlebars template. It's up to you then to transfer/manipulate those data to the model when persisting the associated record. You can also have properties on your model that are not DS.attr and thus won't be persisted.

It would be easier to respond to/understand your problem with a sample.

Cyril Fluck
  • 1,561
  • 7
  • 9
  • An example would be any software as a service model where instead of fully persistence backed models you have a configuration that represents some "in-memory" models (but only at runtime). So what I've done is during the app init (ember) I simply fetch the configuration and build each model the configuration represents on the fly and store it as a simple javascript object (Ember.Object.create). Seems to solve my issue as I like to treat these models like they are persistence backed (even when a database entry per item might not exist on the server side) – Toran Billups Apr 20 '13 at 23:40