Assignment 4: Models, Controllers, and Views
Errata
- (14-Nov-2009) The AddTags migration is missing one tag and had the wrong name for another. Without this tweak, clicking on a couple of publications will raise an exception. So, in AddTags, change the lines that add the tags to this:
%W[ java ruby ruby1.9 rails projects crud models rest activerecord ].each do |tag_name| Tag.create!(:name => tag_name, :user => john) end
- (9-Nov-2009) At the request of Ron, the download version 1.0.004 wraps up a number of small changes from these errata, namely: (a) the use of :uniq on Tag.index_publications; (b) a similar addition on Publication.index_tags; (c) removal of .uniq in views/publications/_publication.html.erb; (d) fix for doubled occurrence of the word “for” in views/index_entries/new.html.erb; (e) a check that there’s a current_user before displaying the link to add an index entry in views/publications/show.html.erb, and, in this same template, another check for a current_user before displaying annotations, as well as the use of the “for_user” association extension on Publication.annotations; (f) from Keith, functional tests of the PublicationsController and SessionsController. That should be it.
- (8-Nov-2009) Thanks to a mistake on my part, I forgot to constrain the indexed publications for a tag so that the results are unique. Ron found the bug and suggested the fix, which works. In app/models/tag.rb, add “:uniq => true” to the indexed_publications association:
has_many :indexed_publications, :source => :publication, :through => :index_entries, :uniq => true
“uniq” is described on p. 371 (print), p. 375 (PDF).
- (5-Nov-2009) For item 1, the CreateIndexEntries migration: The self.down method is already done for you — disregard the comment in the code that says you need to do something. I accidentally left in the drop_table. :-)
- (4-Nov-2009) As I was revising some slides on Rails filtering, a stream of invective emerged from my mouth as I discovered that I had not “turned on” the filtering completely in the code download for assignment 4. This tweak does not affect your ability to get the assignment done, but I recommend it nonetheless. For all controllers except ApplicationController, RequiresAuthenticationController, and SessionController, make sure that the controllers subclass RequiresAuthenticationController. Example:
class TagsController < RequiresAuthenticationController
This tweak is reflected in e168-assignments4and5-jgn-1.0.003.zip on the downloads page. Again, this goof doesn’t really affect your ability to complete the assignment. The sympton is that if you log out and then go to a page such as /tags/new, you won’t properly be kicked over to authentication.
- In app/models/publication.rb, there may be a “for_tag” association extension on on the wrong association. The has_many associations are as follows. This is the only difference between e168-assignments4and5-jgn-1.0.000.zip, and e168-assignments4and5-jgn-1.0.002.zip (001 was missing the update). You can either download e168-assignments4and5-jgn-1.0.002.zip from the downloads page, or put this code below in place of the associations in the Publication model. The reason I wanted you to have this is because I’ll be discussion association extensions Thursday (at Keith’s request) and these additional methods should make it easier to avoid putting “find” code into your views.
belongs_to :user has_many :annotations, :dependent => :destroy do # Students: This is an "association extension": # See AWDR, p. 372 (print), p. 376 (PDF) def for_user(user) find(:first, :conditions => ['annotations.user_id = ?', user.id]) end end has_many :publication_tags, :dependent => :destroy has_many :tags, :through => :publication_tags has_many :index_entries, :dependent => :destroy do # Another "association extension"; see references above. def for_tag(tag) find(:all, :conditions => { :tag_id => tag.id }) end end has_many :index_tags, :source => :tag, :through => :index_entriesThis is fixed in the freshest download: e168-assignments4and5-jgn-1.0.002.zip on the downloads page.
Both assignments 4 and 5 are due 23-Nov.; automatic extension to 25-Nov. If you complete assignment 4 early, submit it, and we’ll see if we can get comments back to you early.
In this assignment you will implement parts of a full-blown web application: migrations, models, views, and controllers. These components are the foundation of any Rails application. If you can do this well, it should be clear sailing to the end of the course, because most of the other aspects of Rails go deeper or decorate the application with plugin or gem functionality.
You can find a package for the assignment on the downloads page.
The application is essentially an online bibliography/index of publications. (We actually wanted to use the word “resource,” but that has a technical meaning in Rails, so we’re going with something a bit more ordinary.) Here’s the home page of the reference implementation (which you can try out at http://publications.plugh.org):
For the most part, the application just gives a list of books and links to web sites. Each publication may have tags and annotations. There are also links to Amazon and Safari when appropriate.
[NOTE regard "Safari" links: For the "reference implementation" and your own app, you can log in as john@7fff.com to see the Safari links; or, in your own implementation, you can set user.safari = true [and save that user] to turn on the Safari links — I decided to leave user management out of this assignment, because it gets complicated fast.]
If a user logs in, there are buttons on the page that allow the user to see the detail for a publication, edit a publication (if the user added it in the first place), and add an annotation (if the user has never added an annotation for the publication). Additionally, in the “detail” view, there are some additional buttons for adding index entries. You will need to play around with the application to get a feel for what’s there. Here’s what the home page looks after a user logs in:
Here’s the schema (click to enlarge):
The central table is publications. As you can see, a Publication has many annotations, publication tags, and index entries. A publication has tags through both index entries and through publication tags. For example, the book Agile Web Development with Rails might be tagged as “rails.” That means there would be a row in the publication_tags table with publication_id set to the id of AWDR in the publications table, and tag_id set to the id for the “rails” tag. There might also be an index entry for the tag “models.” This would be represented by a row in index_entries. The publication_id would be set to the id for AWDR, and the tag_id would be set to the id for the “models” tag.
The annotations table has brief comments on publications. A publication has many of these. Note that a user is only allowed one annotation per publication.
Finally, notice that all of the tables except users have a foreign key user_id pointing back to the users table. By this means, we know who created every row in the application. In general, we only want the user who created a row to be able to edit or delete it. I believe this is implemented completely in the reference implementation, but I might have forgotten a case!
Here’s what you need to do. We have left a number of parts of the application unimplemented. You need to implement them so that they behave in the same manner as the reference implemention (link above). Here’s the list:
- You must implement the CreateIndexEntries migration. The full set of migrations won’t complete without it. The down method is already done (disregard the code comment that says there’s something for you to do — there isn’t).
- You must complete the Annotation model.
- You must validate the uniqueness of the publication_id for a particular value of the user_id. In other words, the combination of publication_id and user_id must be unique. Hint: Study the validations for PublicationTag.
- The presence of the ‘brief’ attribute is required.
- Add a before validation callback that converts all whitespace in the ‘brief’ and ‘full’ attributes to one space.
- On the Publication model, add a custom validation that ensures that there is a value for either the ‘title’ or ‘url’ attributes, or both.
- Add helpers link_to_amazon and link_to_safari in ApplicationHelper that format links to Amazon and Safari. For the formats, hover over the links in the reference implementation. Hint: Implement these by calling the link_to helper with the appropriate values. See the “Note regarding Safari links” above, regarding how to see them in the application.
- In AnnotationController, implement the new, edit, create, update, and destroy actions. It is critical that it be impossible for a user to edit or delete another user’s annotation. For example, the edit URL (in the reference implemenation) is http://localhost:3000/annotations/5/edit. If the current user didn’t create annotation 5, the action should fail (it doesn’t have to fail gracefully; it just has to not work). Hint: See the other controllers. It would also help to compare how the other controllers are implemented, vs. what script/generate scaffold gives you.
- In PublicationController, change create and update so that they can handle the keywords. This is by far the hardest part of the assignment because of the management of the checkboxes. To get some ideas for handling the free-form tag box, take a look at IndexEntriesController. The “Child-Care Coop” application also provides some guidance for checkbox handling.
- Implement views/annotations/_annotation.html.erb
- Implement views/shared/_indexed_publication.html.erb
- Implement the missing parts of views/publications/show.html.erb
That’s it!
@Ron Newman
I just fixed that.
@Lateral Punk
You are only responsible for the 9 items above, so, no, you should not be doing any extra validations there.
Let me look at that controller, though.
When creating new tags in the reference implementation, if you have leading or trailing spaces, or multiple spaces between tags, you'll create an empty tag along with the ones you really wanted.
@Lateral Punk
That's annoying.
The tag shouldn't be blank, and the summary shouldn't be blank, and the combination of tag, summary, and page numbers should probably be unique. I actually deliberately left this lightly validated because I thought it could be very likely that people might have the same tag and page numbers with different summaries, or the same summary and page numbers with different tags; but if all are the same, that looks awkward.
Let us acknowledge, though, that from the user's point of view, this doesn't matter much. As far as the user is concerned, only one blank entry gets added. On our side, we could cull out the "empty" index entries any time we want, so it's just a nuisance at this point.
It would be unusual for an ordinary mortal to make this mistake, as well, because the focus isn't moved into the form. This means that a user has to click to submit (it can't be accidentally submitted with a carriage return unless the user actually switches focus into the form), and since any user who is actually interested in adding an index entry would be doing exactly that, it's probably not a very important issue.
You can try to fix this if you want, but it is far more important that you do the required stuff, and then move right on to assignment 5.
@Ron Newman
I probably left out a + on a regular expression. The field does say "space-separated," so I at least it's doing what it claims.
Let me fix that, since it won't require updating the download.
how can I test helpers? They don't seem to respond in script/console. irb prob don't work. Is it only possible through views?
When we are ready to submit, where should we put any 'writeup' that we want the grader to read?
I also don't understand how to test controllers, helpers, and views. How can I generate a fake HTTP request object (including session and cookie), and make it available to a controller when I call its methods?
@Ron Newman
Put it in /readme-student.txt
To conduct a functional test of a controller subclass ActionController::TestCase (http://api.rubyonrails.org/classes/ActionController/TestCase.html) and then call get and post methods. This test case comes with a bevy of helpful methods. Take a look at the Depot tests, AWDR p. 716 (PDF).
Also, in the latest download, look at test/functional/session_controller_test.rb.
View testing: It depends on what you mean by "view." If you want to test the flow of behavior, try an Integration test (http://api.rubyonrails.org/classes/ActionController/IntegrationTest.html), and, again, check out the Depot examples.
You can also call get and post from the console's app object. E.g.,
>> app.get "/publications" => 200 >> app.cookies => {"_assn4_session"=>"BAh7BjoPc2Vzc2lvbl9pZCIlM2VkODYxN2Q3NmIyMmI1Mjg5ZmJkYjVmYmYxNzc4MjI%3D--67f9e0f49aa15e9cc3d900a85e70e8210b43b10c"}On functional and integration tests, the Rails Guide is particularly good: http://guides.rubyonrails.org/testing.html
As for testing Helpers: I don't know how to do it myself: Keith is the most test-centric developer on our staff: He may have a suggestion.
At this point, testing helpers is easy. Create a test/unit/helpers directory, add a file in the form 'person_helper_test.rb' which becomes 'class PersonHelperTest < ActionView::TestCase'. Methods like assert_dom_equal are really useful in helper tests, since often you're testing that the HTML you're generating is what you expect it to be.
While we know that testing is good, it is not within the 9 Commandments above, so I assume that it is to our benefit but not factored into the grade?
BTW, I have sometimes had Ruby.exe--yes, Ruby--crash on WinXP when running my Rails app. The current request completes successfully (except for loading the stylesheet), but then I have to restart the server to continue. I was able to figure out that when I had a file open for editing, it would do this every time. When I close the file in order to try out the app, it usually doesn't happen, except in the first request or two of a new "session." It is manageable for now, but annoying.
@Mike Bond
For Assignments 4 and 5, you do not have to pass or write tests.
Mike, regarding Ruby crashing on Windows XP: That is really weird. I got a report from Ken Busch - It may be that you are having a similar problem. I'm going to e-mail you both.
Hi John,
the solution is not handling this case:
http://localhost:3000/annotations/destroy/13
where 13 is an annotation that *you* can edit/destroy. Actually, you do remove it from the DB, but it shows some funky error page, which definitely looks weird. I opted to to go back to the home page and show a flash message saying that it was deleted. I think the same happens for a publication that you are trying to destroy...
Just want to be clear about something. Are we to:
1) implement all the tasks as outlined
AND
2) to get our homework working *exactly* like the provided solution.
I ask, because there are things not outlined in the tasks (e.g. I've had to edit routes.rb for example) if I want to handle all the error cases and subtleties, and my my version work to my best when compared with the solution. So is it only 1) or both? I think it's both, but just want to be sure.
another thing, do we hand int both assignments 4 & 5 as one submission, or separately?
@Lateral Punk
Destroy is "not supported" via the HTML interface -- the code is left in so that the controllers will look more like the stock "script/generate scaffold" controllers and be less confusing for you (students). It does work, but to support it properly would have meant rearranging the code for the XML REST interface, and it would have looked very divergent from the code you see in AWDR.
@Lateral Punk
Implement the tasks as outlined; and the behavior for those tasks should be as close as you can get to the reference implementation. Don't sweat it too much.
No changes to routing should be necessary -- send me an e-mail with what you've done with the routes. The reference implementation is EXACTLY what is in the download, except for code that is filled in where there are comments in the code.
@Lateral Punk
This -- "another thing, do we hand int both assignments 4 & 5 as one submission, or separately?" -- good question. I'll have an official e-mail/announcement on that later. Probably two submissions will be best, but i want to check with the TAs to see if they would have a preference. Because an implementation of #5 could change a satisfactory #4 quite a bit, they really have to be two different submissions, even if on the same day.
regarding http://localhost:3000/annotations/destroy/13 -- I don't understand why this 'works' since only HTTP DELETE requests (and not GET requests) are supposed to be routed to the controller's destroy method?
that's weird...
One of the functional tests from Keith seems to fail for me. It's one of the session controller tests. That's especially weird since I didn't change anything on login or session... (wasn't in the assignment). I have fixtures for other tests, but I don't include them in Keiths session controller test (actually I didn't have a functional test for session at all). Might that be the reason?
killkolor@fasty:~/ruby/assn4_books/e168-assignments4and5-jgn-1.0.000$ ruby -I test test/functional/session_controller_test.rb
Loaded suite test/functional/session_controller_test
Started
......F
Finished in 0.226054 seconds.
1) Failure:
test_login_without_return_to(SessionControllerTest) [test/functional/session_controller_test.rb:29]:
expected but was
.
7 tests, 28 assertions, 1 failures, 0 errors, 0 skips
a note of caution: adding a tag like this
alert("you-ve-been-hacked");
works in the reference implementation. You get a nice js popup every time you go there once you added the tag...
I forgot: the alert from above should have a script tag around. I don't try it here... (maybe it works and then everybody who get to this page gets an alert...)
@Ron Newman
Sheesh, I've been waiting for someone to ask that -- so that I can talk about the implications of REST for the rest of your application in lecture.
@Gabriel Hase
Thanks. There is likely a missing [%=h %] ([] substituted for angle brackets).
It is a good thing that html sanitization will be the default for Rails 3.
@Gabriel Hase
One difference between the .003 and .004 versions of the assignment download is this statement in test/test_helper.rb:
fixtures :all
it's commented out in the .004 version. Could this make a difference to your tests? (I don't understand what the statement does.)
@Gabriel Hase
It is a fixture conflict. You can either disable all fixtures (remove the line 'fixtures :all' in test_helper), or fix the test to work with your test data.
why does it keep saying "you-ve-been-hacked" whenever I press a button on the website all of a sudden?
@john
The problem is more subtle that this -- it appears that the link_to() helper does NOT html-escape its first argument.
@Lateral Punk
Because someone put an HTML <SCRIPT> (and also a <H1>) in the name of a tag. That was passed, unsanitized, to the link_to() helper.
I think the moral of the story is that you should almost always use link_to(h(name)) unless 'name' is a constant that you know the contents of.
@Lateral Punk
my bad... I had to try :)
@Gabriel Hase
I'm glad you did -- would never have learned about this security problem otherwise. Now, off to patch my copy of the assignment before I turn it in ....
Do Custom Helpers e.g. AnnotationsHelper have access to the instance variables of the controller e.g. AnnotationsController?
i'm trying to access @annotation which was definied in the controller, but i get back nil in the helper. Am I to pass the annotation from my partial/template to my helper function as such
that seems not so DRY. you would think the Custom Helpers have access to instance variables.
In the PublicationsController I am trying to unravel some mysteries of the update method, and I suspect that ActiveRecord is just smart enough to be dangerous.
Earlier, the checkboxes were behaving properly without my having to do the deletes in the code. That is, if I unchecked something it was properly deleted, even though I had not yet implemented the hint to delete all existing PublicationTags and then start anew. This was a strange fortune to have. However, the free form field wasn't working at the same time. This feature doesn't work anymore as I have moved on to implement the complete solution, so the accidental benefit has disappeared somehow. In any case, I frequently get the following complaint when clicking submit to update:
ActiveRecord::RecordNotFound in PublicationsController#update
Couldn't find Tag with ID=83
I was always getting such messages when I would delete all the publication's PublicationTags in preparation for adding the checked and new ones.
Down below, in the provided code for making the save, we see:
@publication.update_attributes(params[:publication])
The preceding line would seem to be saving whatever the parameters dictate. Is it possible that there is a conflict between the params, which include the checked boxes, and something else? Is there something else going on?
My explanation may not be very clear, but it is because after going around on this for many hours, I no longer even know who I am or why I exist.
Ok, so I was looking for a Tag with a PublicationTag id, so my mistake. Still, I have general problems when deleting all PublicationTags before re-adding the checked ones.
Is it the case that a Full annotation can only be ever seen by the user who created it?
A full annotation can't ever be seen by anyone -- all you get is "(NOTE: There is also a full annotation for this publication.)" if one is present.
thanks Ron.
what's the point of a Publication's URL? If I type in say "www.yahoo.com", and then go peruse it in the details for tha tpublication, I get this as a link:
"http://publications.plugh.org/publications/www.yahoo.com"
this is on the solution. Seems worng to me. How should we handle URL?
try "http://www.yahoo.com" instead. Perhaps the application should automatically add "http://" to an entered URL that doesn't begin this way?
Nobody answered this yet, and I'd also like to understand it. Also, what is the difference between
writing a method in FooHelper, versus writing it in FooController and declaring it to be a helper there?
@Ron Newman
My understanding is that you do have access to the instance variables of a controller in the respective helper.
Helpers are like modules which contain methods to help our views. They extend the behavior of templates. Again the whole point of helpers is to keep your views code DRY. If you have a method in your controller that you want to use as a helper method as well you can make it available to your views as a helper method. But I guess the decision to write a method in a helper class or controller is really depends on whether that method is supporting your view or controller. If you are using your method heavily in views but not in controllers then it makes sense to write it in helper class.
@Ron Newman
I *think* the answer is no, you can't access instance variables inside custom helpers. I *may* be wrong, but the *self* variable inside a helper is *not* your controller. This is just my reasoning.
With regards to your second quesiton, I didn't know you could write a helper inside of FooController. Though it would be my belief that there isn't a difference,but it makes more sense to put the helper in helper files. Also check this out http://railscasts.com/episodes/64-custom-helper-modules
Can someone advise me how best to reset your db and then recreate it? currently I'm doing this:
rake db:migrate VERSION=0;rake db:migrate
But there was another post elsewhere that if you get those two in the wrong order then you risk the chance of getting your db messed up. Don't remember the details, but is't there something like rake:db reset? I"m real paranoid and I like to work with a clean slate every time I build/test :)
@Ron Newman
Sorry I missed this.
Yes, helpers can access controller state and instance variables.
No difference to my knowledge between saying :helper_method in your controller and putting a controller in a Helper class. If a helper is very tightly tied to a controller, I'd use :helper_method. If it's very generic, I'd put it in a Helper class where another developer is more likely to find it.
@Lateral Punk
rake db:drop
rake db:create
rake db:migrate
So how do you access them from a controller. I tried everything, and it didn't work :(
thanks for those commands :)
In the download for Assignment 4, the helper methods logged_in? and current_user are defined in ApplicationController. However there is also an ApplicationHelper with more methods (two of which we have to implement ourselves)
@Lateral Punk
Oh, access a method in a Helper from a controller?
Notice that helpers are modules not classes (I probably wrote "class" a few minutes ago).
So you can include them, just as you can include any module.
include MyHelper
@john
While those commands are useful, they don't quite work the way I want them to. I'm working on a Mac, so don't know how this would be for Windows & Linux users, but let me explain. I always have a SQLite Manager open. with the commands John recommended, I believe that there is a file sharing conflict (I get db/development.sqlite3 already exists) with SQLIte Manager and hence the DB is never re-created or at least that's what I experience. If I refresh in the manager, I still see the same data before the dorp. If I use rake db:migrate VERSION=0;rake db:migrate then things work as expected e.g. things reset. Anyways, I'll stick with the version thing :)
@Ron Newman
I believe there is very little guidance about the advisability of using :helper_method in a controller. I see it infrequently, so I would guess that the feeling is that it's something that most people would actually put in a Helper module -- in part so that it can be included elsewhere. But I think if the method is very strongly associated with your controller -- and no other controller should be able to get at it --, then it's the right place.
(It is even possible that :helper_method isn't in AWDR.)
@Lateral Punk
Well, Sqlite3 is very . . . um . . . lite, you know? You might have to close the database out of the Firefox Sqlite3 Manager or whatever you're using.
Incidentally, you can put those rake commands on the same line, and db:mgrate will create your database if it doesn't exist, so . . .
rake db:drop db:migrate
but I don't see how that gives the helper access to the controller's instance variables, which was the original question here