On Jan 13, 2008, at 4:54 AM, Xavier Noria wrote:
> 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/
--
share your knowledge. it's a way to achieve immortality.
h.h. the 14th dalai lama
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
