Intermediate Ruby on Rails - Part 1

Upcase
1
You will code along with Matt as he builds the application. Do what he does, pause the video if you need to catch up or explore something further. Hop into the forums to ask questions as you have them. We find that the act of doing is a very effec...
This is a companion discussion topic for the original entry at https://thoughtbot.com/upcase/videos/intermediate-part-1
3

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?

4

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 Shout via 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 user_id automatically:

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 shout_parameters method.

Hope that helps

5

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

6

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 user:

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

while with new you cannot save new shout in persistence layer by saving user. You have to call save method on new Shout instance:

shout = user.shouts.new(shout_parameters)
shout.save

Hope that makes sense

7

Hi @sergeylukin

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?

8

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’
bundle
then rails g monban:scaffold works like a charm.

9

Hey, @subratrout!

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!

10

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.

11

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.

12

Hi! I’m new here. Can someone explain why after:
bundle
there’s a need to run:
bundle --without foo

Thanks!

13

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!

14

Thanks @smadeja!

15

Hey guys,

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:

Screenshot at Nov 23 21-23-55.png2202×1242 108 KB

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?

Thanks!

16

Hey @yangc5, so my thoughts would be

  1. to check if a current_user is present
  2. If there is, then assign @shouts to the current_users shouts.
  3. 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

17

OR instead of redirect_to try render ‘sign_in_path’

19

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.

20

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.

21

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.

22

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.