In my view ApplicationController is just about controllers, inheriting
filters, common utilities, etc. I believe any other application-wide
stuff like monkey-patching had a place in Rails pre-2, which was the
bottom of environment.rb, and now the initializers.
but this is a very painful place to do it - you need to get it right the *first time* - either that or restart you webserver each time : it's not reloaded like the rest of your 'application' is. same goes for 'lib' of course. application code should be reloaded in development like, er, the application 
If you are new to a project one of the first things you need to do is
to open environment.rb/initializers and be aware of custom stuff. I
had considered reopening String somewhere under app to be a dubious
practice in the sense that the place is not as conventional as those
are.
yes that's true of course. none would would be as clear as
module Application
module RubyExt
module String
def ellipsis() ... end
end
RubyExt.constants.each{|c| Object.const_get(c).send :include, const_get(c)}
end
end
as i have in some of my projects now though. hacking built-ins should absolutely have a single well known best-pratise place in rails considering that the average application is going to have about 500 files loaded.
Configuration stuff went somewhere in environment.rb or in some .yml
under config. If environment.rb got too big you factored something out
in some file, and require it from environment.rb. But the single entry
point to see custom extensions and global stuff was still that one,
you still saw some require "add_unary_minus_to_nilclass.rb" to follow.
yes i've done both. again this is far less desirable to something like
Application.config.google_ad_client
which is to say there is not a namespace - no best practice - it's just expected that people will litter the global namespace with a bunch of stuff you should trace with grep.
In general I think we do have a place for that kind of stuff, so I am
+1 on the renaming because of the naming coherence.
me too - just to be clear my point is to consider the bigger picture as an aid to determining how it might best be done
I agree an abstract ApplicationModel < AR::Base is missing to complete
a coherent setup. I have not needed such a class very often in
practice, but I think I've reopened AR::Base a couple of times to do
what you normally would do via inheritance. In those cases I didn't
introduce an abstract root model to invest the minimum effort and be
able to leverage the original generators.
a great example is
ApplicationModel < ActiveRecord::Base
before_save do |record|
record.updated_by = ApplicationController.current if
record.respond_to? 'updated_at'
end
end
which, of course, can be done in rails but only with a series of monkey patches. do you really think it's clear to people a) how to do this, b) where it should go? i really don't but maybe i'm just not rails-y enough.
anyhow - i don't want to derail the original thread but thought it worth mentioning that a real refactoring of application.rb might end up with that file returning under a different guise and this suggests a few alternate methods to lessen peoples pain and support new unified application classes. for instance assume that any ApplicationController would also be defined in any such new unified scheme, then rails could simply
%w[ app/controllers/application.rb app/application.rb ].each do |basename>
pathname = File.join RAILS_ROOT, basename
load pathname if test ?s, basename
end
and now it's setup to provide a new style application.rb file and support the old style one - or both.
i'll duck out now since i think my point has been made.
cheers.
a @ http://codeforpeople.com/
