Assignment 3: Milestone II

Here are some finds that I suggest you write prefatory to implementing the version of MetricsMine you will be submitting for a grade. Remember to use the version of MetricsMine I put on the downloads page that has the correct migrations and associations.

It turns out that the “finds” you must do for this application are exceedingly simply as compared to last year’s ChildCare Co-op. The reason is that MetricsMine is preoccupied with data display and not so much with more complicated use cases.

  1. Find all observation sets for a user with id user_id (in the code the user id will come from the session, i.e., session[:user_id]).
  2. Find all observations for a particular observation set; order the observations by the ‘created_at’ column, from oldest to newest.
  3. Find all observations for a particular observation set; order the observations from newest to oldest.
  4. Find all observations for a particular observation set; order the observations by the ‘created_at’ column, from oldest to newest. Ensure that the observation_set is owned by a particular user.
  5. Find all observations for a particular observation set; order the observations from newest to oldest. Ensure that the observation_set is owned by a particular user.
  6. Find the “first” unit of the measurement of an observation kind for a particular observation set. (You may quietly ignore how “first” is defined, i.e., the measurement may have more than one unit; you don’t have to get the “first” one by created_at or any other specific ordering.)

The following is not required, but I will be using it for the implementation of “compare” which I will pass out:



Viewing 13 Comments

    • ^
    • v
    For Milestone 2, where are the finds to be written? That is, is the idea to create specific controllers/methods (actios) which would implement the finds? Or, should we be working in script/console figuring it out?

    Mike
    • ^
    • v
    In the console. This is prefatory work that you will find useful when moving to the implementation of Milestone III.

    The "finds" this semester are quite easy, and most of them will be very similar to find requests in the standard "CRUD" operations in LinkWizz, CCC, etc.

    If you feel confident, you can just move right on to Milestone III -- you will have to use these various "finds" in the implementation, but doing them separately is just intended to be a help along the way, nothing more.
    • ^
    • v
    I'm not sure, but I think the idea is just to write expressions that will implement each of these finds, and not put them anywhere in particular for Milestone II. I suspect that the appropriate places to use these finders will become clear with Milestone III, which I haven't yet explored in any detail.
    • ^
    • v
    Hi John/Amy/Keith/or Harlan,

    Question 1) Why am I having to used nested-hash syntax in order to access the :login value from form_for?

    # if params[:user][:login] == User.find(:first).login #THIS WORKS.
    # if params[:login] == User.find(:first).login #THIS DOES NOT. WHY? THIS IS SUGGESTED SYNTAX.


    Question 2) Why is the login method failing to find a valid :login value in the database. ( In script/console I can use a slightly modified syntax [replacing the params argument with the login string] to easily retrieve the user record.)

    if params[:user][:login] == User.find(:first, :conditions => ["login= ?" , params[:user][:login]]) #NOPE
    # if params[:login] == User.find(:first, :conditions => ["login= ?" , params[:login]]) #NOPE
    • ^
    • v
    I'm not John, Amy, Keith, or Harlan, but I think I can answer these, if I'm right about what you're asking about. These questions don't seem to have anything to do with Milestone II, which is where you've posted the questions.

    If you're asking about the Linkwizz application, which seems likely based on the symbols you're using here, this has been answered in the comments on the download page. There's a bug in the login code, which is looking at params[:login] when it should be looking at params[:user], because the form is a form_for :user. See section 22.4, 22.5, etc. in the AWDR textbook, and also review the lecture slides about forms. There's also some discussion about this in the comments to Milestone III.

    <% form_for :foo >

    will give you a hash in params[:foo], with each key in the hash being the symbol for a field in the form. This is the way Rails is designed, and it lets you pass the entire hash, containing all of the data entered into the form, to the 'new' method for the model class, if you've created your form in the conventional way, with each form field corresponding to an attribute of the model object.

    I don't know where you're getting "SUGGESTED SYNTAX" that skips the model class name, but it's incorrect.
    Question 2: params[:user][:login] is a string. User.find() returns an object of class User. Without some additional code in the User class, these two expressions can't compare as equal.

    Note also that 'find' is cleverly defined to accept a hash for the :conditions, similar to the way 'new' takes a hash. So if the login is the only thing in the form (as it is in the Linkwizz application), then the first version of User.find you've written in your Question 2 is equivalent to the terser

    User.find(:first, :conditions => params[:user])

    which seems to be more idiomatic Rails.
    • ^
    • v
    OK. Thanks for that The combination of the bug, and my not fully understanding the flow of objects had me at a dead end. I also had not seen an example of having to use a nested hash call to access a param field from the view. But it may be that all examples I have come across reference the 'magic' finders based on the general call to :conditions => params[:user]
    • ^
    • v
    I sent an email to Steedman earlier, but Morris correctly summarizes what I wrote. As discussed in class, params is a 'hash-like' object, which means that for all intents and purposes you can treat it like a hash. It is always going to have string-like data when it is passed to a controller from a view, and the keys in the params hash will be dependent upon how you construct your forms. If you are building a form around a model, you will commonly see HTML that looks like:
    <input type='text' name='model[attribute]'>

    and this is converted to a key in the params hash that looks like params[model][attribute]. The hashes can nest even deeper -- it depends on how you construct your form.
    • ^
    • v
    I just downloaded the solution for assignment3 milestone one on the download page. It is not a solution. The migrations and models are not filled in. Could you point me to the right place to download. The link text says that it is a sample solution, but is not.
    • ^
    • v
    On the downloads page, there is a line that looks like this:

    * Milestone I:
    ZIP; Example solution to Milestone I (migrations and associations: ZIP

    You want the second ZIP. I just did. In, for example, app/models/measurement.rb, you see the following:

    class Measurement < ActiveRecord::Base
    has_many :units # 7b
    has_many :observation_kinds # 6b
    validates_presence_of :name
    validates_uniqueness_of :name
    end

    In, for instance, db/migrate/20081025201508_create_measurements.rb you will find:

    class CreateMeasurements < ActiveRecord::Migration
    def self.up
    create_table :measurements do |t|
    t.string :name
    t.timestamps
    end
    end

    def self.down
    drop_table :measurements
    end
    end

    I'm not sure what you're doing. If there is something that is not clear on the downloads page, let me know.
    • ^
    • v
    I got it now. Maybe I clicked on the first ZIP instead.

    Thanks
    • ^
    • v
    Whew! You had me worried that my dyslexia / early-onset alzheimer's was kicking in.
    • ^
    • v
    I've just started on Milestone II and have a question about #1. In parentheses you state "(in the code the user id will come from the session, i.e. session[:user_id])". Are you referring to the web application code? In other words, we shouldn't or can't use session[:user_id] in the finder, therefore, must use some other means?
    • ^
    • v
    No need to answer this. I simply misinterpreted what was being said here. I looked at the child care app (again) and understand what needs to be done.

blog comments powered by Disqus