DISQUS

xertroyt I will e-mail anyone who tells me they're interested.

Or you can take Jim's course: http://extension.harvard.edu/2008-09/courses/cs...

xertroyt Yes, but make sure that you understand: The fact that the foreign key can be null has nothing to do with has_one vs. has_many.

Let's say that model_a is for people, and model_b is for their company: And we say that ModelA has_one :model_b (so a person has 0 or 1 companies - this is not necessarily the way the real world works, but it's how we're going to do it).

Example:

Rows in model_a (columns are: id, name):

1 John
2 Bill Gates
3 Steve Jobs

Rows in model_b (columns are: id, model_a_id, company_name):

1 1 digital_advisor.com
2 3 apple
3 2 microsoft
4 null ibm
5 null dell
6 3 apple
7 1 beatthat.com

NOTICE the following facts:

(1) Even though our association says ModelA :has_one :model_b, it happens that there are TWO rows in model_b where the foreign key is "1" (for John). That is because having just one is not enforced at the database level with more work. I believe Rails will try to enforce the 0 or 1, but if someone forced that row into your table manually, Rails would just bring back one row from model_b when you follow the association from ModelA.

(2) The rows in model_b with nulls for the foreign key value are essentially "orphans." They don't know to whom they belong.

Both of these situations (1) and (2) are problematic. If you want to control whether a null is allows in the foreign key in model_b, look at the ":null" option for columns in the documentation-- in AWDR on p. 277. :null seems not to be in the index.

xertroyt JRuby performs as well or better that the "sandard" Ruby interpreter.

The big advantage of JRuby for web apps is that the JavaEE container can have multiple "Rails" applications running in the same container.

Until recently, in the conventional Rails world, one would literally run multiple copies of Rails on the same physical server.

This blog posting goes over some of the options.

http://weblogs.java.net/blog/arungupta/archive/...

xertroyt Let me say it a bit differently. Let us start with:

ModelB belongs_to :model_a

In Rails, this means that the table underlying ModelB (model_bs) should have a foreign key called model_a_id. That is, a row in model_bs "refers" to a row in the model_as table. In other words, the column model_a_id is a foreign key. ModelB is a "child" of the "parent" ModelA.

The table model_as does not have a foreign key.

When we define ModelA, we can say in our association that it:

has_one :model_b

OR

has_many :model_bs

In the first case, there should be 0 or 1 rows in model_b. In the second case, 0 or more.

The reason you are having trouble with this is in your last paragraph. You write: "Say ModelA has fieldA, fieldB, fieldC. fieldB references ModelB." But that's not how it works. The foreign key is in the CHILD. The parent model DOES NOT HAVE A FIELD that refers to the child. The only way we can "trace" the relationship between ModelA and ModelB is through the *association* -- the *association* (namely, has_one :model_b or has_many :model_bs) is not about FIELDS. It's about a method that allows you to collect up all of the model_bs.

Finally, something to think about is whether ModelB (whose underlying table model_bs has the foreign key model_a_id) is allowed to have a null for the value of the foreign key. This is something you would have to decide for your own application.

I think what I've just written is correct though with names like "ModelA" and "ModelB" I might have gotten something backwards. This is why in the examples I've tried to show somewhat plausible model names like "Book" and "IndexEntry" so that there are some semantics to provide cues as to what is the parent and what is the child.

xertroyt I will leave the screencasts up unless my bandwidth bill increases!

JRuby is a good idea. I'll think about it. I think what everyone would like to see is a Rails application getting deployed into a JavaEE container.

xertroyt A few points:

1. restful_auth gets you more than just the ability to login: It provides for securing your REST data so that unathorized users can't use your service. Open id alone would not get you that.

2. All open id is about is having your credentials clearing happen on another server. By this means, you enter an open id into a site that supports it, and then the check for your credentials jumps to your open id provider. If you check out, then it jumps back to your app. So, in a lot of ways, open id is a whole different thing. Since maybe users don't have open id's, it is a terrible idea to support only open id.

3. You can blend in open id to restful_authentication. I believe there is a screen on this at railscasts.com -- i hcw no idea if the procedure outlined there would work with what I've described in my screencast.

4. There *is* a lot of magic implementing restful_auth. That is why I provide the screencast. It's hard. On the other hand, authentication is also hard (actually really hard to get right -- cookie handling is just the tip of the iceberg).

5. I actually think the restful_authentication plugin is pretty awful. Please don't quite me. There are things coming along that will be better.

xertroyt When you create an OBSERVATION, should its (the observation's) ID (the unique id that identifies a particular observation) be set to the id of its observation set?

No. The observation_set_id on the observation should be set to the observation_set.id. There are two id's in play, one for an observation, the other for an observation set.

When you display a form to create an observation, do you know the id that the database will give a new observation when the form is displayed? No, you don't. The id should not be specified at all for the :create action, because when the create action takes over, it will get the new id from the database.

Would you e-mail me privately? john at 7fff dot com

xertroyt I don't understand what you're saying, because you're not using the language of the application.

If you are deleting observations (metrics), you would use the checkbox and then click "delete checked." There is only one button here, so I don't know what you mean by "each delete key I hit."

If you are deleting observation kinds -- "kinds of metrics" in the UI -- you would be clicking the delete link.

Note that when an observation kind is deleted, then the display of the KIND at the top of the "show" page for the observation set can no longer display the kind. So it is blank. There is an instruction regarding this in the static page for the "show" template.

xertroyt That is correct: When you display a particular observation set, save the current observation_set_id to user.current_observation_set_id.

I cannot reproduce the "automatic" disappearance of observation kinds, or any error page. If you delete all of the observation kinds (PLEASE DON'T!) you will find that you can't create a new observation set (I think). This was discussed earlier, and we said: "An admin would never delete all of the observation kinds, so we will consider this a feature, not a bug."

I have just reset the database. If you can identify a set of seps that will produce this behavior, from login to the error, e-mail the steps to me.

xertroyt What is the username that you are using with http://metricsmine.plugh.org that doesn't work in FF 3.0?

When you say: "why do you need o save the information in the database as well as in the cookie ?", what do you mean by "the information"?

xertroyt Sadly, I'm afraid, this is one of those areas where the view helper docs are not as comprehensive as they should be.

See what happens if you say:

<%= form.datetime_select :observed_at, { :include_seconds => true } %>

This is by analogy to

http://api.rubyonrails.org/classes/ActionView/H...

where there is this comment:

# Creates a time select tag with a seconds field that, when POSTed, will be stored in the entry variables in
# the submission_time attribute.
time_select("entry", "submission_time", :include_seconds => true)

xertroyt You must implement it in the same fashion as the reference implementation. Do not introduce extra controller actions and/or views.

So, this means:

-- The controller/action that sets up the form must be: ObservationSetsController#show
-- The form displayed by views/observation_sets/show.html.erb must be "for" the :observation model
-- That form must post back to the :action => :create_observation (on ObservationSetsController)

Are you doing those things?

xertroyt I don't see how that would work.

Think about it this way:

-- You set an instance variable.
-- A form is displayed.
-- The user clicks "submit" or "add observaiton" (whatever's on the button).
-- Now a new controller receives the request (i.e., the "post" of the form)

How does this new controller know what observation_set_id you want?

You have to get that observation_set_id into the params hash.

And how do you do that? Include the observation_set_id in a hidden field.

xertroyt To see how you get directed to the page on which you would add an observation:

(1) Log in.
(2) close your browser without logging out.
(3) Go back to the application. See where you end up?

If this doesn't work for you, let us know.

Reason for this behavior: There is ONE activity that the user wants to do every day: Post data. If you have ever tracked your weight, you will do anything to avoid this behavior. Therefore, the application makes it as easy as possible.

Keith The instance variable doesn't persist to the next request. When you click on 'Add', you won't have access to @observation_set_id any longer.

Keith Looks like that is a bug.

xertroyt I see that there are some answers already to some of these questions, but here are some brief confirmations of what is below:

-- When an observation is added, it must be added TO an observation set. Therefore, when the form that lets you add an observation posts back, there must be some indication of the observation set id to which that observation should be added. Therefore: (a) you may pass the observation_set_id to the form in an instance variable; (b) use a hidden field to capture that id so that it is sent back when the form is posted; (c) in the action to which the form posts, obtain the observation_set_id from the params hash.

-- For time forms in forms: Take a look at the ChildCare Co-Op application. The helper is: datetime_select - it has many options.

Morris For selecting a time in a form, there are helpers for this in the ActionView::Helpers::DateHelper class. http://api.rubyonrails.com/classes/ActionView/H...
I thought I had seen an example of this somewhere in John's sample code, but I can't find it now. I'm fairly sure AWDR gives some examples.

You could pass the observation set id as a parameter in the URL for the form, but my personal interpretation of the requirement not to change the HTML is that we're supposed to use the hidden field in the form, which will make all of the information stay in the POST parameters. There are helper methods for hidden fields.

xertroyt It's a validation. Like all validations, it does not happen in the view markup (that is, not in text_field or any of the other helps).

Validations are declared on the model. I explained how these validations worked a few lectures ago.

If you will take a look at the Observation model in the latest download, you will see that the following has already been declared for you:

validates_numericality_of :amount

If you want to display the results of that validation, you will need to use the error display helpers -- for examples of that, see CCC or LinkWizz, or the lecture slides.

xertroyt The session id in the log starts with the session id -- the extra stuff (e.g., "CkB1c2VkewY7CUY=--b6c94f16882989fe21d2a65e2858309809d2bab9") is an encoding of what is actually stored in your session. I am not 100% sure where the session id ends and the new data begins, but that is the way sessions work for the cookie store.

So: I don't think this has anything to do with your sessions.

Review your code for adding a measurement. Are you accidentally calling a method to delete a measurement?

I understand why you say, for instance, that you "redirected to the correct page." However, you have a bug, so it is futile to claim that your code is correct. You need to keep looking at it.

xertroyt Those session id's like identical to me.

One thing that could be happening is that somewhere you are redirecting to the wrong page -- or, possibly, you are calling a method in your controller twice.

Why don't you go on to the other parts of the assignment anyway? I don't think you should let this hold you up.

Morris You should already have the correct stylesheets included, if you're starting with the contents of the downloaded zip file. All of the necessary stylesheets are in the public/stylesheets directory, and the default application layout file links to those stylesheets.
In the supplied material as I've downloaded it, the stylesheets directory contains 8 stylesheets, and the application layout in the layouts directory references 7 of them.

If you "view source" with your browser on any page that has a button, for example the users/login page, you can see the HTML for the rectangular blue button, and the corresponding .html.erb file for that view will show you the Rails code that generates that HTML.

Morris Re: the "UTC". It looks like if you just print out the value of a 'created_at' field, it comes out just right: the default format for ActiveSupport::TimeWithZone#to_s appears to be exactly what we want.