I am developing my first Rails application, which tracks job statuses for a job shop. I have the following models:
class Job < ActiveRecord::Base
has_many :parts
...
end
class Part < ActiveRecord::Base
belongs_to :job
end
I would like to have a page with a form that accepts a scanned barcode as input. It would find the Part object in the DB using the barcode ID and would set the Part.completed_at attribute to the current time.
I am trying to keep everything as RESTful as possible, and so at first it would seem like this page should be a view for the edit action in the Parts controller. However, in this view I don't yet have the Part object. What is the best way to implement this functionality? Should it be a new action in the Parts controller called something like find_and_update? Thanks in advance for steering me in the right direction.
You can implement a new non-RESTful action called find_and_update, that will work just fine.
If you want to keep it RESTful:
1) you could have a PartCompletions controller, that has a create action that accepts an ID. That is to say, when you submit a barcode, you are "creating" a "part completion". One of the light-bulb moments people have learning REST with Rails is when they learn that your RESTful controllers don't have to map 1-to-1 with your models / database tables. You can create new abstractions to help stick to the RESTful verbs (create, read, update, delete).
2) If you didn't want to create an extra controller, you could use the update method of your existing PartsController. That is to say, you're "updating" a "part" and giving it some new values (in this case a new completed_at date). You'd pass it the id from the barcode reader, and also pass it a hash with the new values you want to change (ie, that'd mean passing in the completed at field with the current time in your post request, rather than setting it in your controller action)
Either of these two approaches can be fine - as is the non-RESTful option, too - it depends on how big your app is, how many other non-RESTful actions you're likely to end up having if you don't strictly follow REST, etc. The smaller and more self-contained your app is, the more it's OK to break REST and other conventions/patterns in order to save time and keep it simple up front. My advice: don't spend too long agonising over which approach is the best. Pick one, and write code. You can re-factor it later.
Let's say I have a controller called Books (and a corresponding Book model), and a controller called Users (and a corresponding User model). Each of these controllers has the standard CRUD actions, and they serve as the vehicle for my website's API as well.
Most of the pages on my site fit into this framework easily. For example, viewing a book. Or viewing your user account. Or editing your user account. Etc.
But let's say I have an index that will be somewhat unique: I want to show a list of users AND a list of books. This raises a few questions:
What controller should this go under: UsersController, BooksController, or a new controller?
If I create a new controller, is that considered a violation of any MVC principles since it won't be tied to any particular model in particular?
How would this new controller action retrieve the data? If I write new ActiveRecord queries inside if it, them I'm repeating myself, since I already have code like this in my other controllers. I'd also prefer to consume my own API, if possible.
You can use scopes(google search it) in your model to keep your controllers lean. Depending on what you want to show you can create a new method and view. lets say you have a user dashboard that list your books and the authors which are in seperate models.
you can create a new method called def dashboard inside your user controller since it relates to your user.
def dashboard
end
you would create a helper method in your model to scope the specific queries. Remember to also add the proper route to your routes file.
I hope this helps
Whichever you want.
1) I would probably write another controller, though it may end up to be a question of taste and it may change with the context of the application.
2) I would fetch the data from both models. There is no MVC rule mapping controllers and models one to one.
I am not quite sure what you mean by "queries" but you can put them in model methods (or scopes) to avoid DRY. Of course one gets tempted to do simple queries in controllers because ActiveRecord encaplulates them as methods (e.g. User.find(n) )
I am new to Ruby on Rails and the whole MVC style of doing things. This question isn't so much technical as it is conceptual. Say I have some function myFunction that I wish to have a user execute from the View by pushing a button. Should I have this function in thew Model, or the controller?
If the function relates clearly to a particular model e.g. "placing an Order", "authenticating a User" then place it on the appropriate model and add a small amount of controller code to create/retrieve the appropriate model and call the method.
If it doesn't obviously belong on one of your models then you may want to create a separate class or module for it, and again add a small amount of controller code.
Do some Googling for "skinny controllers and fat models", this is the approach generally favoured for Rails projects. e.g. see this (old, but still useful) post from Jamis Buck, or this more recent post.
It should goes to controller's method which is using models to do some business logic (not necessary connected with persistance). Probably, you should also read about RESTful apps and routing (there is a lot of guides about it).
Controller's are just expected to have the Input and Output which is the request parameters and the response/redirect. So according to you if a user clicks a button and myFunction should come into picture. Put the call to myFunction inside the view helper and the function myFunction inside the model. So your View is also clean from code and the Skinny controller and Fat models come into picture
I'm really new to Rails (for coldfusion) and before I even start coding I want to make sure I understand the convention and apply it right.
One of my concern is the following situation using Rails convention:
I create a table called users
I create a model called User.cfc
I create a controller called Users.cfc
create a register page so I will add a method called register in the controller Users.cfc since its specifically related to the model User.
But now lets say I create a method that call multiple model then where should I put that method?
Example:
I'll take facebook wall post for this example. For each of my post many comments can be added. So I could create a method name postMessage so in that method I would call the model "Post" and also the model "Postcomment" so my question is should I put the method postMessage in the Controller "Posts" or "Postcomments"?
That really depends on the purpose of the method. If it's a user who's looking at his collection of Widgets, you might create a "widgets" method in the Users controller.
On the other hand, if you want to list all the users who bid on Widget #32, then you might add a "users" method to the Widgets controller.
There is no definite rule with these types of things. While you generally want a 1-to-1 correlation between Models and Controllers in Rails, there are exceptions. You may have some Models without their own Controllers (e.g. Login, EmailAddress), and some Controllers with no associated models (e.g. Home, Admin).
In Ruby on Rails Development (or MVC in general), what quick rule should I follow as to where to put logic.
Please answer in the affirmative - With Do put this here, rather than Don't put that there.
MVC
Controller: Put code here that has to do with working out what a user wants, and deciding what to give them, working out whether they are logged in, whether they should see certain data, etc. In the end, the controller looks at requests and works out what data (Models) to show and what Views to render. If you are in doubt about whether code should go in the controller, then it probably shouldn't. Keep your controllers skinny.
View: The view should only contain the minimum code to display your data (Model), it shouldn't do lots of processing or calculating, it should be displaying data calculated (or summarized) by the Model, or generated from the Controller. If your View really needs to do processing that can't be done by the Model or Controller, put the code in a Helper. Lots of Ruby code in a View makes the pages markup hard to read.
Model: Your model should be where all your code that relates to your data (the entities that make up your site e.g. Users, Post, Accounts, Friends etc.) lives. If code needs to save, update or summarise data related to your entities, put it here. It will be re-usable across your Views and Controllers.
To add to pauliephonic's answer:
Helper: functions to make creating the view easier. For example, if you're always iterating over a list of widgets to display their price, put it into a helper (along with a partial for the actual display). Or if you have a piece of RJS that you don't want cluttering up the view, put it into a helper.
The MVC pattern is really only concerned with UI and nothing else. You shouldn't put any complex business logic in the controller as it controls the view but not the logic. The Controller should concern itself with selecting the proper view and delegate more complex stuff to the domain model (Model) or the business layer.
Domain Driven Design has a concept of Services which is a place you stick logic which needs to orchestrate a number of various types of objects which generally means logic which doesn't naturally belong on a Model class.
I generally think of the Service layer as the API of my applications. My Services layers usually map pretty closely to the requirements of the application I'm creating thus the Service layer acts as a simplification of the more complex interactions found in the lower levels of my app, i.e. you could accomplish the same goal bypassing the Service layers but you'd have to pull a lot more levers to make it work.
Note that I'm not talking about Rails here I'm talking about a general architectural style which addresses your particular problem.
Perfect explanations here already, one very simple sentence as conclusion and easy to remember:
We need SMART Models, THIN Controllers, and DUMB Views.
http://c2.com/cgi/wiki?ModelViewController
The Rails way is to have skinny controllers and fat models.
Do put stuff related to authorization/access control in the controller.
Models are all about your data. Validation, Relationships, CRUD, Business Logic
Views are about showing your data. Display and getting input only.
Controllers are about controlling what data goes from your model to your view (and which view) and from your view to your model. Controllers can also exist without models.
I like to think of the controller as a security guard/receptionist who directs you the customer(request) to the appropriate counter where you ask a teller (view) a question. The teller (view) then goes and gets the answer from a manager (model), who you never see. You the request then go back to the security guard/receptionist (controller) and wait until you are directed to go another teller (view) who tells you the answer the manager (model) told them in response to the other teller's (view) question.
Likewise if you want to tell the teller (view) something then largely the same thing happens except the second teller will tell you whether the manager accepted your information. It is also possible that the security guard/receptionist (controller) may have told you to take a hike since you were not authorized to tell the manager that information.
So to extend the metaphor, in my stereotyped and unrealistic world, tellers (views) are pretty but empty-headed and often believe anything you tell them, security guard/receptionists are minimally polite but are not very knowledgeable but they know where people should and shouldn't go and managers are really ugly and mean but know everything and can tell what is true and what isn't.
One thing that helps separate properly is avoiding the "pass local variables from controller to view" anti-pattern. Instead of this:
# app/controllers/foos_controller.rb:
class FoosController < ApplicationController
def show
#foo = Foo.find(...)
end
end
#app/views/foos/show.html.erb:
...
<%= #foo.bar %>
...
Try moving it to a getter that is available as a helper method:
# app/controllers/foos_controller.rb:
class FoosController < ApplicationController
helper_method :foo
def show
end
protected
def foo
#foo ||= Foo.find(...)
end
end
#app/views/foos/show.html.erb:
...
<%= foo.bar %>
...
This makes it easier to modify what gets put in "#foo" and how it is used. It increases separation between controller and view without making them any more complicated.
Well, it sort of depends upon what the logic has to deal with...
Often, it makes sense to push more things into your models, leaving controllers small. This ensures that this logic can easily be used from anywhere you need to access the data that your model represents. Views should contain almost no logic. So really, in general, you should strive to make it so that you Don't Repeat Yourself.
Also, a quick bit of google reveals a few more concrete examples of what goes where.
Model: validation requirements, data relationships, create methods, update methods, destroy methods, find methods (note that you should have not only the generic versions of these methods, but if there is something you are doing a lot, like finding people with red hair by last name, then you should extract that logic so that all you have to do is call the find_redH_by_name("smith") or something like that)
View: This should be all about formatting of data, not the processing of data.
Controller: This is where data processing goes. From the internet: "The controller’s purpose is to respond to the action requested by the user, take any parameters the user has set, process the data, interact with the model, and then pass the requested data, in final form, off to the view."
Hope that helps.
In simple terms, generally,
Models will have all the codes related to table(s), their simple or complex relationships (think them as sql queries involving multiple tables), manipulation of the data/variables to arrive at a result using the business logic.
Controllers will have code/pointers towards the relevant models for the job requested.
Views will accept the user input/interaction and display the resultant response.
Any major deviation from these will put unwanted strain on that part and the overall application performance may get impacted.
Testing, Testing ...
Put as much logic as possible in the model and then you will be able to test it properly. Unit tests test the data and the way it is formed by testing the model, and functional tests test the way it is routed or controlled by testing the controllers, so it follows that you can't test the integrity of the data unless it is in the model.
j