This is a companion discussion topic for the original entry at https://thoughtbot.com/upcase/videos/intermediate-part-1
Can someone explain this line?
shout = current_user.shouts.build(shout_parameters)
I’ve always done:
@shout = Shout.new(shout_parameters)
How is it different?
Hi @greggawatt I’m a student like you here learning Ruby so I may be wrong, but the way I see it when you create a new
User model you don’t have to worry about the association between them (and as a result in having shouts that are associated with an incorrect user), so this sets
shout = user.shouts.build(shout_parameters)
while this one does not set
user_id unless you permit it in
shout_parameters method and pass it via HTTP request parameters:
shout = Shout.new(shout_parameters)
So, ideally you want to use the former way and only permitting shout parameters that are not related to the association (like
user_id) in private
Hope that helps
correct me if im wrong but is the question comparing ‘build’ vs ‘new’? because I think build is just an alias for new, so u still needs current_user in creating a new shout so that you wont need to know the id of the current_user
According to my knowledge
build is doing exactly what
new does, additionally it updates the Collection with which new Model is associated. So after using
build to create new user shout, you could save new shout in persistence layer by calling
save method on
shout = user.shouts.build(shout_parameters) # now user.shouts contain new shout # and you can run .save method on either user or shout shout.save # or user.save
new you cannot save new
shout in persistence layer by saving
user. You have to call
save method on new
shout = user.shouts.new(shout_parameters) shout.save
Hope that makes sense
While that makes sense, I fail to understand the downside of using
.new( ) instead of
.build( ), in what situation would you want to save the user object rather than saving the shout itself, when creating a new shout?
I am using Rails 4.2.4 and Ruby 2.2.2p95
When tried to do rails g monban:scaffold I got following errors:
Could not find generator ‘monban:scaffold’. Maybe you meant ‘erb:scaffold’, ‘scss:scaffold’ or ‘css:scaffold’
Upon reading monban documentation I found out that:
we have to include monban generators and i.e by adding gem ‘monban-generators’
then rails g monban:scaffold works like a charm.
With more recent versions of Monban, you’ll also need to include
monban-generators in your gemfile. That will enable you to run
rails g monban:scaffold.
Please let me know if that helps!
I think the strong_parameters gem isn’t required anymore since it’s included in Rails? I was getting the following error while trying to run rails g monban:scaffold:
“superclass mismatch for class ParameterMissing”
Removing the strong_parameters gem fixed it.
You’re right, Tim. Rails 4 comes with strong parameters out of the box.
Any Rails 4 app won’t need to use the strong_parameters gem.
Hi! I’m new here. Can someone explain why after:
there’s a need to run:
bundle --without foo
You wouldn’t normally have to do it. The idea is that if you run
bundle --without assets, the value of the ‘without’ option is remembered, and running
bundle --without foo (‘foo’ being just a random text, not referring to any real group) overwrites that.
I don’t think this trick works in recent versions of Bundler, though.
Anyway, if you’ve run bundle once, you should be good to go, no need to play with the ‘without’ option. Have a look at Bundler docs for more information. Cheers!
I finished this tutorial and have a question about the authorization process:
When not signed in, I tried to access the dashboard page with url ‘localhost:8080/dashboard’, I got this error:
Is there anyway to redirect unauthorized users to sign in page instead of showing the error when the user is trying to access a page they’re not supposed to see?
Hey @yangc5, so my thoughts would be
- to check if a current_user is present
- If there is, then assign @shouts to the current_users shouts.
- If there is NOT, then redirect_to your sign_in_page_path
def show @shout = Shout.new if current_user @shouts = current_user.shouts else redirect_to sign_in_page_path end end
replace [ sing_in_page ] with whatever your path is for your sign in. (I have no done this path yet but bout to start now) so hopefully this helps a little
OR instead of redirect_to try render ‘sign_in_path’
Ruby 1.9.3 and Rails 3? Are you serious!? Does anyone update these videos? Rails 4 has significant advantages over Rails 3. Also, Ruby 2.3.0 is out now, why would we want to use Ruby 1.9.3?
Sorry to say this, but it just seems that this video is very old and I am seriously considering why I am paying for a subscription when the content is out of date. I could be wrong, but I’d like an explanation.
Was listening to a recent Giant Robots episode, I believe they’re revisiting this course to bring it more up to date. Cant tell you the exact episode as it was a couple of weeks ago.
I have to agree. Its always hard to know if some content is still maintained. And seeing those obsolete
versions may indicate that its not worth the time, going through this course.
Clarification of updates of the content may be helpful.
The vast majority of the material in the course is still completely applicable to Rails 4 and Rails 5.
But I believe there’s actually an accidental benefit to this covering an older version of Rails.
In the real world, you won’t always to working with the most up-to-date Rails version. For a variety of reasons, many companies still have ‘legacy’ Rails 3 apps in production.
By knowing about the evolution of Rails, you will gain a better understanding of why particular things are they way there are, e.g. why strong parameters succeeded attr_accessible, and the particular quirks of each release, etc.