Validation can fail user.errors is a hash of the fields with errors and the detailed message. User.create makes a new model and saves it to the database.Method save can fail if the model is not valid. new does not save to the database: you must call user.save explicitly. User.new makes a new object, setting attributes with a hash.There’s two ways to create new objects: joe = User.new( :name => 'Sad Joe' ) # not savedīob = User.create ( :name => 'Happy Bob' ) # saved

Be careful - the model in memory acts like a cache that can get stale. You need to call user.reload to get a fresh query. If you already queried for videos, s may have stale data. You create a new video, point it at the right user, and call s to get a list. Using ActiveRecord class User value pairs. Models are fat in Railsville: they do the heavy lifting so the controller stays lean, mean, and ignorant of the details. The web server is the invisible gateway, shuttling data back and forth: users never interact with the controller directly.

However, it’s important to mention how the controller magically gets created and passed user information. Many MVC discussions ignore the role of the web server.

Models do the grunt work, views are the happy face, and controllers are the masterminds behind it all. It’s more fun to imagine a story with “fat model, skinny controller” instead of a sterile “3-tiered architecture”. The server combines the raw data into a proper HTTP response and sends it to the user. The controller returns the response body (HTML, XML, etc.) & metadata (caching headers, redirects) to the server. The show view generates the HTML: divs, tables, text, descriptions, footers, etc. In our example, the controller gives video 15 to the “show” view. They don’t know what happens in the back room. Views are merely puppets reading what the controller gives them. They’re the sales rep putting up flyers and collecting surveys, at the manager’s direction. Views are what the user sees: HTML, CSS, XML, Javascript, JSON. In this case, the model retrieves video 15 from the database. They’re the chubby guy in the back room crunching the numbers. They talk to the database, store and validate data, perform the business logic and otherwise do the heavy lifting. It asks the model to get video 15, and will eventually display it to the user. In our case, the show method in the video controller knows it needs to lookup a video. The best controller is Dilbert-esque: It gives orders without knowing (or caring) how it gets done. They’re the pointy-haired manager that orders employees around. The web server then uses the dispatcher to create a new controller, call the action and pass the parameters.Ĭontrollers do the work of parsing user requests, data submissions, cookies, sessions and the “browser stuff”. In our case, it’s the “video” controller, method “show”, with the id parameter set to “15″. It uses routes to find out which controller to use: the default route pattern is “/controller/action/id” as defined in config/routes.rb. The web server (mongrel, WEBrick, etc.) receives the request. Here’s the big picture as I understand it: This isn’t quite an intro to MVC, it’s a list of gotchas as you plod through MVC the first few times. I’m glad people liked the introduction to Rails now you scallawags get to avoid my headaches with the model-view-controller (MVC) pattern.

Rails find by undefined method map