This is the file for brainstorming before I start modifying the main tutorial
- some issues in current code examples
- there’s a redundant fetch in one of the later examples
- trying to oversimplify server interactions means that we’re handling IDs on the client when should handle ID assignment only on the server
- why? Because in real life you’ll be using a database or something of that form where the IDs will be generated by saving in the database
- some of the interactions between views and models are simple but not idiomatic
- Not enough motivation
- there’s explanation for what MVC is, but not why you should care
- there need to be bigger better examples of what MVC buys you
- simplifying many-to-many and many-to-one relationships?
- Doesn’t cover routers
- this is a pretty big oversite
- Doesn’t outline a proper end-of-tutorial project
- need
- learning objectives
- steps
- hints
- need
- Demonstrate multiple views
- this is related to the many-many many-one relationships mentioned earlier
- what would make good examples?
- this is related to the many-many many-one relationships mentioned earlier
- How about a microblog that displays user information next to tweets
- but also has a list in the lefthand side with all the current users and, mayhaps, their total number of tweets and some other different details. We want to keep all of the data synced to the model and with its own user interface componenets.
- Social network of professional relationships, call it “cuff linked”
- display multiple users and, say, two layers deep of connections to other people
- if a connection is added in one place between people then it should update everywhere else in the visual hierarchy
Explain
- Setting basic URLRoot
- saving without an ID means a POST
- saving with an ID means a PUT
- fetching data means a GET
if we cover this more thoroughly here it will probably help structure the tutorial better once we get to collections (e.g. collections are just formalized groups of models where you don’t have to set the model’s url route you just have the collection handle that)
What we can explain is that if we know how many models we want, then we can hardwire the site to have specific IDs and never use POST: because POST should only be allowed if it makes sense to increase the number of models, the same way that DELETE only makes sense if you’re allowed to decrease the number of models.
We can contrast this by showing how to make a button that creates new model/view pairs for counters, which actually uses POST to create new models. The point of this exercise is that we can then contrast it with what model and view collections buy you.