Please read for an updated status on RailsCasts:
Learn more or hide this
GitHub User: RobertDober
Thanks for the cast Ryan you spelt it well as usual. But somehow I share that kind of disappointment with Cyle. It is not if anything were missing, it is just there is no big Wow as there has been before with major releases. Probably a good sign for maturity...
You seem to keep improving all the time Ryan
we need a vote button here to give you some stats ;).
For now just take this high praise please:
@Ryan I hope we are not abusing the comment space with this.
@Erwin it would surely be nice to have a postprocess method, but my real issue with at_exit was that I need to know when the
callbacks are registered.
Thus it might be a good idea to have the postprocess inside Rails::AppBuilder and let Rails::AppBuilder expose some
register_* methods like register_first, register_last etc.
Another possibility would be, that a register method returns the registered block, which later can be used to specify dependencies. Voilà an example:
class AppBuilder < Rails::Appbuilder
@rspec = register do
register after: @rspec do
generate 'I:Do:Not:Know:What' # ;)
Erwin's solution is a nice one and scales better than mine. However mine is a little bit easier on the fingers as it does not require the --skip-bundle option.
@generator.gem 'rspec-rails', group: [:test, :development]
At first I was afraid that the free episodes' quality might suffer from the pro and revisited episodes. That is definitely not the case, I am, well, impressed. Thx for all these efforts.
Nice gem, nice presentation.
I would like to add a little suggestion. My watching experience would be even better if the lines in mate were wrapped, or broken up. As I often stop to read the code again - I am a fast learner if given plenty of time - I found it difficult to grasp the full context of the initializer file, line #9, stardate 2:10 to 2:20.
Thanks for the great work again.
I definitely like the approach.
Because "@" should be used for addressing people ;).
@miguelsan,@tio: Agree with you, one should not even have to call expose for RESTful resources. I would rather prefer to have to tell the controller when *not* to expose or when the model name and controller name do not match. We could have nested resources exposed automatically too, by inspecting the routes.
@Ryan: I am confused about the default behavior of the expose(:comment) in the nested resource example. I understood, that you left it as the default because there was no id param. Would that not have worked too? I mean by delegating to the scope of :comments, which was article.comments, would that not have yielded article.comments.find(param[:id]) ?
Incredible amount of information passed on!
I'd loved to see you implementing the link_to_function in the view before you wrote the spec for it and having it fail. I know you would have had two failures, firstly the problem with the missing feature and secondly the problem with the missing :js => true. I understand that for a cast, as packed as this one, that might have been too much.
However that is just so much the workflow, that happens to me all the time.
Hmm after all, maybe this cast, which I still consider one of the greatest for my own interest and benefits, might have been worth being split into two....
But I appreciate that great balance of simple, intermediate and advanced casts.
Thank you for the great work
great idea to have a RC more on the metal this time, seamed like a very nice voyage in time :).
@Tim, I'd say paranoiac: your ivar is living during the request only! I admit though, that paranoiac is good when it comes to security ;). However, you also need to flush the params hash and maybe one or two other things. And probably the object in which you are flushing is going to die very, very soon after the save, and flushing before the save might not be a brilliant move ;).
Almost overkill to point out that the shorter Railscasts have often lots of value, and hey why make it more complicated than it is ;).
Thanx for this episode as much as for all the others.