First time asking something here on StackOverflow. So excited!
Basically, I'm wondering what the correct design pattern is for what I'm trying to accomplish. I have all my code working but was wondering it there's a more elegant, "RoR Way" to put it all together. For a language/framework so beautiful, it just feels like I've done this wrong:
I have a single master layout page ("WeekSummary") I'm using to display a bunch of "DaySummary" shims. All shims derive from the same template "_day_summary.html.erb."
On WeekSummary, I'm able to pass variables to individual shims fairly easily, eg:
<%= render 'layouts/day_summary', date: '2016-08-12' %>
<%= render 'layouts/day_summary', date: '2016-08-11' %>
But now I'm having trouble invoking a "day_summary" controller definition per each shim. Essentially, at this point in the render lifecycle, I believe I've already passed through the "C" part when the RoR engine called my "week_summary" definition (in which I did hold some business logic). But now I want the RoR engine to go back to the controller and call a "day_summary" controller definition per each shim I've defined on WeekSummary view page. I would like all variables/definitions to be then locally scoped to each shim (so I can reuse the same var names, etc).
I wasn't able to figure out how to do that though so right now I've simply dumped all my shim-specific business logic at the top of the "_day_summary.html.erb" in a massive <% %> block. Having so much business logic there in a View shim seems wrong though.
I hope this made sense. Does anyone have any suggestions for how to properly do this? Essentially, I'm trying to encapsulate the rendering of each shim into its own MVC lifecycle/pattern, if that makes sense. Thank you!
Edit: In response to kcdragon's code request on what's happening inside each shim:
So, for example, for each day_summary shim, I wish to calculate that day's pnl.
At the top level, in the week_summary controller def, I get all transactions:
#transactions = Transaction.all.order('ticker', 'date DESC')
Then in each shim, I filter #transactions by only the date I care about for that shim. Thus, a sample of each shim's business logic includes the below-- in this example, calculating that day's PnL:
transactions = #transactions.where(date: '2016-08-08')
pnlHash = Hash.new
totalPnl = 0
transactions.each do |t|
if !pnlHash.key?(t.ticker)
pnlHash[t.ticker] = t.pnl
else
pnlHash[t.ticker] += t.pnl
end
totalPnl += t.pnl
end
<%= totalPnl %> is then rendered elsewhere on the shim.
There's other business logic too that happens in the shim, but this is a good representative sample.
Now, obviously at the top level (week_summary), I could "pre-process" all daily PnL calculations and then store them in some massive hashtable which I'd then use to extract values per day_summary shim. (In this example, I guess that'd be a true model of the week_summary view.) But I don't want to do that. I want to encapsulate day_summary into its own thing, where all its business logic and rendering is processed on the fly as week_summary renders. Hopefully that makes sense?
Edit2: For sake of clarity, here's what each day_summary shim looks like. On the week_summary view, five of these guys are rendered, each one corresponding to its respective date:
Here's what the day_summary shim looks like.
Related
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 template that users can upload that generates a report. They can put special tags into the html template and it will replace with data from the db. Quick example:
<div class="customer-info">
<h1>{customer_name}</h1>
<h2>{customer_address_line1}</h2>
<h2>{customer_address_line2}</h2>
<h2>{customer_address_city}, {customer_address_state} {customer_address_zip}</h2>
</div>
I have a controller that looks up the customer and then parses the template and replaces the tokens.
Right now I have the parse code in the controller creating a fat controller. Not good.
But where should I move the code? Model folder? Create a Util folder and put it there?
Just not sure what the Rails Way would be.
I was curious about this too, and found a very similar discussion here. Honestly, I think it depends on how much parse code there is. If there are only a very few lines, then the model is a safe place. If it's going to be a large package, especially a re-usable one, the /lib/ folder may be a better bet for the parsing itself. However, you definitely should remove it from the controller, as you suggested.
I agree that the logic shouldn't be in the controller, but let's get a
little more specific about how you'd go about implementing this.
First, where are you storing your templates in the database? They
should be stored in their own model, let's call it
CustomerTemplate and give an attribute :template of type Text.
So now we have two types of objects, Customers and
CustomerTemplates. How to render a customer given a template? It
honestly wouldn't be terrible to just have a render function in
the CustomerTemplate model that takes a customer and renders it, but
it is putting some logic inside your app that doesn't strictly belong
there. You should separate out the "customer specific rendering logic"
from the "rendering my simple custom template language".
So, let's create a simple template handler for your custom language,
which I'm going to nickname Curly. This handler should know nothing about
customers. All it does is take a string and interpolate values inside
{}'s. This way if you want to add new template types in the future —
say, to render another model like an invoice — you can use the same
template type.
Templates in Rails are classes which respond to call and are
registered with ActionView::Template. The simplest example is Builder.
Here's a quickly written Template handler which renders Curly. The
call function returns a string which is eval'd, so the string has to
be valid ruby code. The string eval in scoped by the render call, so
it has access to any variables passed in via the { locals: {} }
option to render.
# In lib/curly_template_handler.rb
class CurlyTemplateHandler
def self.call(template)
src = template.source
"""
r = '#{src}'.gsub(/{([^}]*)}/) { |s|
local_assigns[$1.to_sym] || s
}
raw r
"""
end
end
Make sure the handler is initialized, and let's set it to listen for
the :curly type.
# In config/initializers/register_curly_template.rb
ActionView::Template.register_template_handler(:curly, CurlyTemplateHandler)
We need to add lib/ to autoload_paths so the class is loaded:
# config/application.rb
config.autoload_paths += %W(#{config.root}/lib)
Finally, we can render our template in our view! I'm embedding the string here, but you'd really get it from a CustomerTemplate object:
<%= render(inline: "<h2>{customer_name}</h2><p>{customer_address}</p>",
type: :curly,
locals: { customer_name: #customer.name,
customer_address: #customer.address }) %>
DO NOT USE MY EXAMPLE CODE IN PRODUCTION! I left out a bunch of corner
cases which you'll need to handle, like sanitizing user input.
I'm wondering if there's a specific programming principle (Demeter?) that supports the idea that Rails helpers should never use controller instance variables, rather, they should receive such variables as function parameters. For example, assume my ChickensController#squawk action creates an instance variable called #egg. Furthermore, assume the squawk view contains a call to a helper called cockadoodledoo, implemented like so:
def cockadoodledoo
#egg.to_s
end
Would it be better or unnecessarily verbose to pass #egg as a parameter, such that the view calls cockadoodledoo(#egg) and for the helper to resemble:
def cockadoodledoo(egg)
egg.to_s
end
I hope one of you happy hackers is bored enough on a Friday afternoon to assert an answer. Cockadoodledoo!
This question here is similar, but was never accurately answered.
Receive them as a param. Otherwise, as the app grows, it gets very difficult to trace where the instance vars are being set when refactoring, troubleshooting, etc.
Also, I believe there's a general best practice to only use instance vars in views within the initial template...and from there you should pass the var into helpers and other partials.
I'd say you should always pass the variables explicitly to your helper for 2 reasons:
you control exactly what you do
above all, you can test your helper
I don't know if there is any named principle governing this sort of thing but I would pass an argument. Not only will the argument make your helper easier to test and your application's data flow easier to follow but it will also let you use one helper for a single instance as well as a list; if you pass an argument then both:
<%= cockadoodledoo #egg %>
and:
<% #eggs.each do |egg| %>
<%= cockadoodledoo egg %>
<% end %>
will work as expected without introducing a special cockadoodledoo that handles a list in #eggs rather than a single #egg.
Since helper messages are mixed in to all controllers, hence available to all views (including partials and layouts), it's always wise to establish a clear contract - the parameters.
The only exception I could think of is when a instance variable is also available to all views and controllers, like a menu or something similar.
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.
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]