Please read for an updated status on RailsCasts:
Learn more or hide this
GitHub User: nicholaspufal
I would really like to see that also.
Btw, don't you guys think that many of these methods could be extracted into a Presenter?
Since they all affect the presentation of the information (they do not modify the data itself), I think would be much better to see it on a Presenter.
The same is not valid to Tag/Category creation, of course.
I made my wi-fi public when I tested.
Can it have something to do with OS (I'm on Lion)? I'm not a big understander about networks, but with the wi-fi public shouldn't I see it?
Of course, when doing from my computer I'm able to see that cookie session info, but even that way, when using cURL, I was not logged in. It just redirected me back to the sign_in path.
Any ideas of what could be wrong? I'm just following the same steps.
Thanks for this episode. I never was really aware of this issue.
However, I tried to reproduce the steps in my local network using a Rails app that was already deployed, and the cookies didn't appear anywhere when using tcpdump.
I tested it using my wi-fi network, and 2 different machines (mine and another). When I tried to login using the other machine, none of that info appeared in tcpdump.
I'm using Devise for the authentication.
When I tested it in my local machine, then I could reproduce the vulnerability and see all the cookie information.
Am I missing something? By what I understood, shouldn't I be able to see it when in my local network (and not only localhost)?
Thanks a lot for this :)
Ryan, do you by any chance have in mind doing an episode similar to this, but focusing also on polymorphic associations, or associations in general?
Maybe it's just me, but I find very difficult to work with Arel when in those situations. Specially polymorphic. The solution is always do SQL by hand.
After this Railscast I found out that internally Rails is handling the build of the associated object when needed. It seems that this behavior has in fact changed.
The only thing I needed to add is a instantiation of my join model to the action 'new'.
I have a Proposal model which can have many Product through a join model called ProductEntry.
In the action 'new' from my ProposalsController I simply added:
@proposal.product_entries << ProductEntry.new
This is just to display the form field when no ProductEntry is available yet, which is always the case when I'm creating a new Proposal.
When I go and edit a Proposal, Rails automatically instantiate all ProductEntry that are associated. If I edit any of those ProductEntry (such as the quantity attribute that I have), it simply works too.
How this would work when the models are associated via a has_many :through association?
I'm trying to follow the same steps, however nothing is displayed in my form.
I remember that the first episode regarding this topic used to build the objects in the controller, e.g. Question.new, so that they would be made available in the view. I found really weird that this wasn't mentioned this time.
Did that behavior changed in Rails?
In order to make it work with has_many :through I need to build "by hand" the associated object in my controller?
That's the why Ryan suggests the "h" method. It's an easier way to access the @template attribute.
That way you could do something as:
handle_none user.name do