Generate supermodels inside modlets

[justinbmeyer]

The current supermodel generator creates a the model and its test in the models folder, and a fixture file in the fixtures folder as follows:

├── todo.js
├── todo_test.js
├── fixtures/
|   └── todo.js

Unlike components, this does not use modlets.

Pros:

• less folders for a dev to work through.
• there's often only a model and model_test file necessary
• fixtures files are less important as fixture is being used more directly within tests or demo pages now.

Cons:

• not consistent with components
• there maybe other files necessary
• there's no individual test page for that model.

  Alternatives

  Modlet with plural fixture

├── todo/
|   ├── todo.js
|   ├── todo_test.js
|   ├── test.html
|   └── todos.js (this would be the fixture)

Considerations:

• this would require something to pluralize the model name.

  Modlet with fixture

├── todo/
|   ├── todo.js
|   ├── todo_test.js
|   ├── test.html
|   └── todo_fixture.js 

Modlet with fixture out

├── fixtures/
|   └── todo.js
├── todo/
|   ├── todo.js
|   ├── todo_test.js
|   └── test.html

[JaneOri]

I'm in favor of the "Modlet with fixture" approach.

The modlet approaches also give us a good place for a demo.html if we decide we want/need one.

[justinbmeyer]

Also related: https://github.com/donejs/donejs/issues/509

[Alfredo-Delgado]

My 2 cents:

What's most important when dealing with models is recognizing that they are a horizontal concern spanning the entire project, like design, as opposed to disparate strata in vertical feature implementations.

With this in mind, how models are organized should take into account individual model requirements vs. datasource requirements. e.g.

• Datasource
  • connection
  • behaviors
  • fixtures
• Model
  • itself
  • tests

Edit: Modlet with fixture out jibes best with this line of thinking.

[BigAB]

@Alfredo-Delgado You think the Datasource and related should be separate from the Model?

I am trying to think of a use case....

I can't think of one, why wouldn't it be:

• Model
  • itself
  • connection
  • behaviour
  • fixtures
  • test

What is the benefit of splitting out the connection and behaviours? Would they be shared by multiple models somehow?

[Alfredo-Delgado]

@BigAB, hierarchically speaking, this is what we're dealing with.

• Datasource
  • connections
  • behaviors
  • fixtures
  • models
  • tests

If you wrote your own behavior to address something about Datasource then you would incorporate it into your own connection factory (i.e. your version of superMap) and it would be shared among that datasource's models.

Your datasource might support different kinds of connections. Maybe you want one without your special behavior, or one with your special behavior but no caching, etc.