I looked in the Rails docs under inflector and found this message...
Module deprecated
This module is deprecated on the latest stable version of Rails. The last existing version (v2.1.0) is shown here.
There was no explanation or reference to any further detail.
I recalled seeing a Rails Trac website. I hunted that down and found that it too is deprecated. It referred me to Lighthouse.
I found some info there -- the Rails core team is not accepting patches for inflections.rb. But it didn't really explain the deprecation message. What is the story behind that?
You might take a look at this post for an explanation.
I'm looking at the Edge Rails source code for inflector.rb right now and I can't see anything to say that it's deprecated—where did you get that information from?
Patches aren't being accepted because they might break legacy code that's relying on incorrect inflections. You can add your own rules by accessing the singleton instance yielded by Inflector.inflections, as shown below:
ActiveSupport::Inflector.inflections do |inflect|
inflect.irregular 'person', 'people'
inflect.uncountable 'rails'
end
Two separate issues at play. Inflections won't be patched to correct errors to protect legacy uses of incorrect inflections but more importantly inflections was moved into ActiveSupport as of 2.2.1
see 2.2.1 here versus pre 2.2.1 here
Related
I'm using this gem - https://github.com/paulelliott/fabrication and I've inherited some specs that contain the following
Fabricator(:tenant_user) do
user!
tenant!
end
For the life of me I can't find any documentation to detail what the bang is actually for... any ideas - or ideally a link to documentation?
Just got an answer from Paul who created the gem. Answering here as might be useful for anybody else.
'That is an old syntax that was deprecated with version 2.0.0. If you are on a newer version than that you can safely remove them.
If you're on an older version, those tell Fabrication to generate the model immediately instead of on 1st access. Without them it will wait until you actually call the field accessor to generate the associated model.'
I've tested this by running rails c both before and after git stash. On Rails 4.1 in Mavericks, after following the instructions to add the versions table and adding has_paper_trail to three models, whenever I run rails c I get
irb: warn: can't alias context from irb_context.
I've spent some time Googling without much luck, there's old threads talking about rspec, but I don't see how that's relevant since I'm not using it. Any ideas why this is happening?
RSpec used to polute provide Object top-level methods, e.g. describe, context, etc. Fortunately they've got rid of all the monkey patching in version 3, and now all these methods are namespaced under RSpec.
One can change this behaviour through the expose_dsl_globally config flag. For backwards compatibility, it defaults to true.
The warning shows up when you open the console because paper_trail automatically loads its rspec helpers when rspec is found. And it calls RSpec.configure before you have the chance to tweak your own configuration.
One possible solution would be paper_trail to disable the automatically loading and let users to load it themselves when they see fit. However, I am not aware of the internals of the library, so I can't guarantee this wouldn't break other things.
Best!
This is now fixed in papertrail 4.0.0, here's the commit.
In the documentation for Rails::Plugin (for Rails 3), I'm reading the following:
"... you actually cannot declare a Rails::Engine inside your Plugin, otherwise it would cause the same files to be loaded twice. This means that if you want to ship an Engine as gem it cannot be used as plugin and vice-versa."
Can anyone be more specific about exactly what files get loaded twice? I have declared a plugin/gem as Engine, and it works fine also being put inside vendor/plugins (and I'd like to keep it this way), in spite of the statement above. I simply want some clarity on why (and whether) this is not a good thing to do.
Thank you!
I don't have an exact answer myself, but this subject is covered in this resource which I have found helpful:
https://gist.github.com/e139fa787aa882c0aa9c
Where can one find a list of deprecated methods, APIs, etc, in order to upgrade from Rails 2.x to Rails 3?
The Rails 3 release notes have lots of good information:
Railties now deprecates:
RAILS_ROOT in favor of Rails.root,
RAILS_ENV in favor of Rails.env, and
RAILS_DEFAULT_LOGGER in favor of Rails.logger.
ActionController:
The cookie_verifier_secret has been deprecated and now instead it is assigned
through Rails.application.config.cookie_secret and moved into its own file:
config/initializers/cookie_verification_secret.rb.
filter_parameter_logging is deprecated in favor of
config.filter_parameters << :password.
ActiveRecord
named_scope in an Active Record class is deprecated and has been renamed to just scope.
save(false) is deprecated, in favor of save(:validate => false).
model.errors.on is deprecated in favor of model.errors[]
ActiveRecord::Base.colorize_logging and config.active_record.colorize_logging are deprecated in favor of Rails::LogSubscriber.colorize_logging or config.colorize_logging
ActionMailer
:charset, :content_type, :mime_version, :implicit_parts_order are all deprecated in favor of ActionMailer.default :key => value style declarations.
Mailer dynamic create_method_name and deliver_method_name are deprecated, just call method_name which now returns a Mail::Message object.
ActionMailer.deliver(message) is deprecated, just call message.deliver.
template_root is deprecated, pass options to a render call inside a proc from the format.mime_type method inside the mail generation block
The body method to define instance variables is deprecated (body {:ivar => value}), just declare instance variables in the method directly and they will be available in the view.
Mailers being in app/models is deprecated, use app/mailers instead.
I don't think you'll find an exhaustive list of depreciations because it really depends on what version of rails you are upgrading from. For instance, Rails 2.3.9 (just released) added additional depreciations over the previous release.
The Rails Upgrade Handbook (as mentioned above) is a great tool and contains 12 pages of depreciation warnings and how to fix them. I don't think they'll be published here because you should just drop the $9 and download the pdf to get the list. The included tutorials and other information makes it well worth it. It was for me.
If you don't want to pay for good information then just run the rails_upgrade plugin for your specific application. More information on how the plugin is on the rails upgrade plugin github page.
A good way of checking the specifics about an individual app would be to run the rails_upgrade plugin on it (you can find it at GitHub), it will output a list of deprecation notices and recommendations
Some useful info is also summarised in this blog post: http://www.simonecarletti.com/blog/2010/07/the-way-to-rails-3/
Additionally Railscasts has a bunch of movies on various changed aspects of the API. Go to Railscasts.com and browse the movies filed under the rails3 tag.
I found it to be a great value to buy http://www.railsupgradehandbook.com/
Another place to have deprecation's for active record is here (http://m.onkey.org/active-record-query-interface).
Reply if found useful.
How to disable colorize logging in ActiveRecord without Rails? Instead of keeping AR decoupled, independent ORM, it is now tightly bound to Rails framework.
Moving ActiveRecord::Base.colorize_logging to Rails::LogSubscriber.colorize_logging was just bad design and the wrong direction, wasn't was?
When I run...
$ script/generate
I get a list of installed generators and a message saying "More are available at http://wiki.rubyonrails.org/rails/pages/AvailableGenerators." However, the indicated wiki page says "This topic does not exist yet."
Does there exist some central repository of downloadable Rails generators?
In particular, I'd like one that creates the Rails scaffolding, but uses Haml instead of ERB.
It would also be neat if it would generate the Test::Unit tests but using the Shoulda enhancements.
That wiki was a wonderful resource back in the day, but it's long gone. I threw up a archive containing that page from when the wiki started wobbling. It's dated but you can at least see what was there.
As for now, look for gems (especially plugins) to provide the generators rather than expecting them as isolated resources. The gems command can be used to find whats available.
A lot of plugins come with their own generators. The one that springs to mind is restful_authentication because I have used it quite a bit.
Edit: Did you google here?
There's Rails Boost, which is a template generator. In fact, the template you want has already been generated -- that one uses HAML and Shoulda.