DISQUS

Stu · 1 year ago

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?

Stu · 1 year ago

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.

student1 · 1 year ago

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.

jgn · 1 year ago

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.

student1 · 1 year ago

I got it now. Maybe I clicked on the first ZIP instead.

Thanks

jgn · 1 year ago

Whew! You had me worried that my dyslexia / early-onset alzheimer's was kicking in.

Steedman · 1 year ago

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

Morris · 1 year ago

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.

Keith · 1 year ago

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.

SLB · 1 year ago

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]

philadelphia · 1 year ago

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

Morris · 1 year ago

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.

jgn · 1 year ago

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.