This example is not my real app, but it's modeled pretty closely to it.
My mom schedules a couple hundred employees at a local warehouse. In their system, a worker can earn "points" for being late or missing shifts. Here we have a sort of summary screen for my mom, who may need to follow up with new employees or discipline employees with concerning levels of points.
Questions that arise as I code something like this:
- Which objects deserve presenters?
Any object with a decent amount of complexity in the view. I prefer to refactor presenters out. Therefore they grow out of complexity and true need rather than up-front design.
- Should I allow HTML in my presenters?
I usually do. The only reason I see this being an issue is when you need to present different formats (json). If you reach this complexity then it may be worth splitting one presenter off into multiple formatted presenters, one for each format.
- Do partials help or do they actually hide complexity that should be
I generally use partials for two reasons: 1) for removing duplication in the view. 2) for representing HTML content behind complex logic.
- Is this amount of logic ok in a view, if it's tested? (Views are essentially methods, right?)
I think so, but maybe borderline. It looks like the core logic is nicely factored into the model, so the if statements are each a simple, single clause. One thing that bothers me is the
elsif
after the longif
block. The only other thing is the closing</p>
tag inside the if statement. Ick.
See the code below for how I would refactor this into a presenter based on RailsCasts episode 287
Of course, those kinds of questions make a 2 hour feature take a day...
Don't worry about the questions so much. Do the feature in two hours and then refactor that as you see fit. The key is to stay disciplined in refactoring which allows you to make ugly code at first just to do the simplest thing that could possibly work.