More and more I'm putting all of my code in models and helpers concerning MVC.
However, sometimes I'm not sure where to organize code. Should it go into the model or should it go into a helper. What are the benefits of each. Is one faster or are they the same. I've heard something about all models getting cached so it seems then like that would be a better place to put most of my code.
For example here is a scenario that works in a model or in helper:
def status
if self.purchased
"Purchased"
elsif self.confirmed
"Confirmed"
elsif self.reserved
"Reserved"
else
"Pending"
end
end
I don't need to save this status as in the database because there are boolean fields for purchased, and confirmed, and reserved. So why put this in a model or why put it into a helper?
So I'm not sure of the best practice or benefits gained on putting code into a model or into helper if it can be in both.
Your specific example is including a business rule in the sense that if the instance of the model is both purchased and confirmed then the proper status is "purchased" not "confirmed"
So in your example, I'd definitely put the method in the model since it is coding one of your applications business rules.
A different example:
def status_string
case status
when 0: "Purchased"
when 1: "Confirmed"
else
"Pending"
end
end
In this case, the status_string method could be reasonably defined either in a View Helper or Model--it has nothing to do with any business rules, it is changing the representation of the value. I'd put it in the model since I tend to only put html-related sw into the View Helpers. But depending on your internationalization scheme, a similar method might be better placed in the View Helper.
A good example of a View Helper is an application-wide method to transform date time values into the standard representation for your app. Eg
# application_helper.rb
def date_long_s(d)
d.strftime("%A, %b *%d, %Y *%I:%M %p")
end
This is really subjective and I agree, sometimes it is not clear if something belongs in a model or helper.
For example:
# using model
status ? status.nice_name : "Pending"
# using helper
nice_name(status)
The clear advantage here for the helper is that it can handle nil objects gracefully keeping views clean. The disadvantage is that the code is now in a different location away from the model
Performance wise you will not see any significant difference between using helpers and models. It is more likely that DB round trips to pull status objects will be a bottleneck.
I use constant hashes in this kind of situations.
Hash is defined in model file like this
STATUS = {
1 => "Pending",
2 => "Confirmed"
}
I also declare constants for each status like this.
ST_PENDING = 1
Declaring this is useful when writing queries. For example,
MyModel.all(:status=>ST_PENDING)
status field in database table is number.So when printing, I simply use this.
MyModel::STATUS[obj.status]
Related
I have a method to check if a User can edit either a post or a comment on my Rails application. Because a user can own both types of entities, I decided to make this method take either of them as a parameter post_or_comment:
class User < ActiveRecord::Base
def can_edit?(post_or_comment)
post_or_comment.user == self || self.admin?
end
end
Is this a good practice to ambiguously take any object like this as a parameter, and does the name I chose for the parameter make sense?
I am not interested in a sophisticated user-role handler like CanCan, as I am learning and would rather keep it simple.
If it's understood that within your schema a post is a type of comment or vice-versa then it's not really all that confusing to express it in the form of one or the other with the implication that it applies equally to both types.
Generally it's best to avoid overly restricting things unless you have a very good reason. There's ways of turning your very specific method into one that probably works most of the time, and if not it's because you're passing it an unowned thing:
def can_edit?(thing)
# Admin can edit anything.
return true if (admin?)
case (thing)
when User
# Users can edit themselves
thing === self
else
if (thing.respond_to?(:user))
# If the owner matches.
thing.user === self
else
# Don't really know, so say no by default.
false
end
end
end
The worst case failure state for this code is that it says "no". Now you can pass in arbitrary things that may or may not have a user property and it will work as expected. For other special cases you can add another when to the main case.
I was reading an article about Rails controllers, can you help me understand please what is meant by the following phrase:
"The best controller is Dilbert-esque: It gives orders without knowing (or caring) how it gets done."
Is it true, in your opinion?
If, for example, I am accessing the index page associated with the subjects controllers, I would define the index method in the subjects_controller.rb rigorously, so I am confused as to what they mean in the article, as I would have thought the opposite.
Any pointers, please?
Thank you and sorry if this is too interpretable. This is the original article: http://betterexplained.com/articles/intermediate-rails-understanding-models-views-and-controllers/
This article is talking about MVC architecture. What's important to take away from an article like this is the fact that Rails is best written with Fat Models and Thin Controllers. This means that you want to have the bulk of your methods/functions in your Model and want to have calls to the functions from your controller. Index is a bad example since typically you're not going to have a lot going on in there.
Your controller for index will typically look something like this
def index
#subjects = Subject.all
end
If you want to scope order for displaying your subjects though, you would do that in your model with a block as follows:
default_scope { order("id DESC") }
A less contrived example might look something like this: Say for example you have an app that accepts input, takes that input and tallies several counters based on what the user entered. Your controller might be named subject_tally and look like this:
def subject_tally
#subject = Subject.find(params[:id])
#subject.winnings += 1
#subject.total_matches += 1
#subject.win_percentage = #subject.winnings.to_f/#subject.total_matches
redirect_to subjects_path
end
THIS IS WRONG. This is a very fat controller and easily moved to the Model where it should be.
If written properly it would look something like this:
subjects_controller.rb: (The Controller)
def subject_tally
#subject = Subject.find(params[:id])
#subject.subject_tally
redirect_to subjects_path
end
subject.rb: (The Model)
def subject_tally
self.winnings += 1
self.total_matches += 1
self.win_percentage =winnings.to_f/total_matches
end
So as you can see, you make only one call from the controller and it "doesn't care" what is actually going on in the backend. It's literally there to pass a value (in this case, the ID of the subject in question) and direct you to another page, in this case, the index.
Furthermore, if you'll notice, you don't need to add that pesky #subject everywhere in your model's subject_tally function... you can reference the attributes of the object just by using self.winnings where you're assigning to an attribute. Ruby is smart enough to know the current subject the method applies to (since you called that function ON a subject from the controller) and in fact you don't even need the self. if you're just retrieving the attributes instead of assigning them... which is why we didn't need self before winnings.to_f or the last line's total_matches.
Very convenient, less code, less time, yay.
The best controller is Dilbert-esque: It gives orders without knowing
(or caring) how it gets done.
means that you should put less logic as you can in the controller,
the controller should only know what to call to get what it needs, and should not know how to carry out a certain action.
In the "Sandy Metz rules" for rails developers (http://robots.thoughtbot.com/sandi-metz-rules-for-developers), she says:
Controllers can instantiate only one object. Therefore, views can only
know about one instance variable and views should only send messages
to that object
only one object could seem a bit extreme, but makes the idea about how much business logic (no logic) you should put in the controller.
I have a model called Feature with a variable called body_string, which contains HTML markup I'd like to render, rather than escape.
Every time I reference body_string in my views, I need to use <%=raw or .html_safe. This seems redundant and not-so-DRY.
Is there any way that I can establish once-and-for-all the body_string variable as html_safe?
I'm assuming this would happen in the app/models/feature.rb file, but I can't figure out what the right syntax would be, exactly. I've thought of this:
def body_string
return self.body_string.html_safe
end
But Rails doesn't like it; it raises a stack level too deep exception.
Naturally I could define a variable/method with a different name:
def safe_body_string
return self.body_string.html_safe
end
And then just change all references in the views from body_string to safe_body_string. But somehow this seems almost as un-DRY as simply using raw or .html_safe in the first place.
Any insights to how best to handle this? I feel like there must be something really elegant that I'm just not seeing.
Just use read_attribute to avoid the recursive call to body_string:
def body_string
read_attribute(:body_string).html_safe
end
read_attribute is complemented by write_attribute for setting attributes from within your model.
A note on style: Don't use explicit returns unless you actually need them. The result of the last statement in a method is implicitly the value returned from the method.
While #meager's answer will definitely work, I don't think this logic belongs in a model. Simply because it adds view-level concerns (HTML safeness) to the model layer, which should just include business logic. Instead, I would recommend using a Presenter for this (see http://nithinbekal.com/posts/rails-presenters/ or find a gem for this -- I personally love Display Case). Your presenter can easily override the body_string method and provide the .html_safe designation when displaying in the view. This way you separate your concerns and can continue to get body_string from other models without mixing in the view concern.
Maybe this gem is useful for you. I also wanted to stop repeating html_safe all the time when the content is completely trustable.
http://rubygems.org/gems/html_safe_attribute
Or you can also use this approach,
def body_string
super && super.html_safe
end
In Django, there's the existence of a message framework which notifies the user after an action is performed. For instance, from the views.py there might something like:
if success:
messages.success(request, 'Update Successful')
else:
messages.warning(request, 'Something is missing')
I believe Rails have something similar with:
flash[:notice] = 'Something is missing'
Should the messages above be hard-coded in the controller?
If I understand your question, you are asking whether or not you should hard-code a string value into your code. In compiled languages, you often use a reference to a string, instead of entering the actual string. ala:
message.success(request, message_resource.success )
This gives you the freedom to change the string value without re-compiling the code, and has a performance benefit in some instances.
Because Python is dynamic this really isn't required, but depending on the size of the project, may be beneficial.
Imagine a situation where the software is used by people speaking different languages, you could detect the required language somewhere else in your code and initialize message_resource.success, as well as any other strings, to be in said language.
here is a simple example:
german.py
# german language messages
success = "Sie folgten!"
failure = "Sie fallen aus!"
english.py
#english language messages
success = "You succeeded!"
failure = "You fail!"
main.py
# main
# import english language
message_resource = __import__('english');
print message_resource.success
print message_resource.failure
# import german language
message_resource = __import__('german');
print message_resource.success
print message_resource.failure
In Rails any marshallable object can be put in the flash.
Therefore it is better to do it in the view.
<% if flash[:notices] && flash[:notices][:missing] %>
<div><%= t("Somethign missing") %></div>
<% end %>
Putting text and translations in the controllers is indeed a bit ugly..
Messages are events. Things that happen. Which is what the "controller" part of MVC is all about. The "how".
(Django calls this "view functions".)
The model is (mostly) stuff that's static, final, persistent. Passive. The "what".
Things happen to the model. Things are initiated by the controller.
Messages come from the controller for presentation to the person.
It's possible that a model's method might need to provide some evidence or information on a state change. This is not an example of a message being created by the model. If the model has methods that do mutation/update/state change, then you have to break things into two pieces.
The "controller" (i.e., Django view function) must use the model's API to make the state change and collect any information on that state change.
The "controller" (the view function) does I18N translation and presents the message.
generic examples
Model: The method is_missing() would go in the model, if it is dependent only on the data.
Controller: Marshalling data from the model for the view: missing = Suff.get_by_id(1).is_missing()
View: <span>{$missing}<span>
But exactly where you draw those lines is always up for debate. In your example, I would say flash, success, and warning are over-stepping their bounds on how to present the data and would be better in the view since they are generic data presenters.
I'm sure this has been asked already, but I can't find the answer.
I have a Project model, which has a belongs_to relationship with my Client model. A client has a name, but a project doesn't necessarily have a client.
In my view, I've got code like this:
<%=h project.client && project.client.name %>
because if the project doesn't have a client then trying to access project.client.name causes a NoMethodError (nil doesn't have a method called name).
The question is, is it acceptable to have this kind of nil checking in the view, or should I be looking for another way around it?
Just use
project.client.try(:name)
I think its perfectly acceptable - this is view logic, you are more or less deciding whether or not to show portions of your view, based on whether there is data.
I run into this all the time, and yes it's annoying. Even when there is supposed to never be a nil, dirty data that I inherited sometimes triggers it.
Your solution is one way of handling it. You could also add a method to Project called client_name that displays the client name if it exists, but then you are linking the models together more than some people recommend.
def client_name
client && client.name
end
You could also make a helper method to do it, but you can end up writing a lot of them. :)
As mentioned by Skilldrick below, this is also useful to add a default string:
def client_name
client ? client.name : "no client"
end
You can use delegate in your Project class, so this way you will respect the Law of demeter which says that you should "talk only to your immediate friends".
project.rb
class Project
delegate :name, to: :client, prefix: true, allow_nil: true
end
So this way the project object will know where to ask about the client's name:
#You can now call
project.client_name
See more about delegate in the Rails documentation.
my hacky solution is to yield a block and rescue the error. Many would say using rescue as logic is very bad form. Just don't use this where you would actually need to know when something is nil and shouldn't be.
In application_helper.rb:
def none_on_fail
begin
return yield
rescue
return "(none entered)"
end
end
Then in the view:
<%= none_on_fail { project.client.name } %>
Then methods can be chained as deep as needed and it can be used on any method BUT it will cover up other potential problems with models/relationships/methods if they exist. I would equate it to taking out a splinter with a flamethrower. Very effective with painful consequences if used improperly.
I think these checks can usually be eliminated with a bit of thought. This has the benefit of keeping your view code cleaner, and more importantly, keeping logic out of the view layer, which is a best practice. Some templating engines don't allow any logic in the view.
There are at least a couple of scenarios. Let's say you have a show action that depends on an instance variable. I'd say if the record is not found the controller should not render the html, by redirecting or something else. If you have a loop in the view for an array, use #array.each do |a| end so that it doesn't evaluate if the array is empty. If you truly want an application default in the view, try loading it from a config file, e.g. #page_title || #{#APP_CONFIG['page_title']} (see Railscasts #85). Remember you may want to change these strings later, for example translating the UI.
Those are a couple scenarios where presence checks and usage of try can be avoided. I'd try to avoid them if possible. If you can't avoid them, I'd put the conditional checks in a view helper and add a helper unit test for it to verify (and document) both code paths.