application.rb -> application_controller.rb
Michael Koziarski
judging by the torrent of +1 votes on this ticket, there are a lot of
people who feel that way.
http://dev.rubyonrails.org/ticket/10570
So, if we want to ship something like this in 2.1 we should make sure
it's going to work well. So in addition to renaming the file in newly
generated applications, we'll need to have a strategy for people
upgrading from earlier versions.
Ideally rake rails:update would be able to warn the user that the file
needs to be renamed, if not do the rename itself. If possible it'd
be nice to support both names for a while in trunk to avoid any
surprises for people running on edge[1].
Will this change enable any new 'stuff' that at present you can't do?
Referencing controllers from production.rb being the obvious case.
Finally, as we'd no longer be preloading ApplicationController, is
there anything which might be relying on this?
I'm definitely keen on fixing it up, I'm just worried that a torrent
of empty +1s may swamp any back-and-forth about the risks and benefits
to making the change.
[1] I think you're crazy to be running on edge right now, but some
people like it :)
--
Cheers
Koz
Assaf Arkin
>
> The special-case nature of 'application.rb' is a bit of a smell, and
> judging by the torrent of +1 votes on this ticket, there are a lot of
> people who feel that way.
>
> http://dev.rubyonrails.org/ticket/10570
I still find it confusing that the class ApplicationController resides
in a file called application.rb, not following the class/file naming
convention used elsewhere.
But I also find it confusing that it's called ApplicationController to
begin with, given that it doesn't expose any actions and I never route
to it. It's simply a base class for application-wide functionality.
So why not call it Application?
Controller superclasses don't have to use the Controller prefix, as
evident by ApplicationController::Base.
Assaf
-- http://labnotes.org
> So, if we want to ship something like this in 2.1 we should make sure
> it's going to work well. So in addition to renaming the file in newly
> generated applications, we'll need to have a strategy for people
> upgrading from earlier versions.
>
> Ideally rake rails:update would be able to warn the user that the file
> needs to be renamed, if not do the rename itself. If possible it'd
> be nice to support both names for a while in trunk to avoid any
> surprises for people running on edge[1].
>
> Will this change enable any new 'stuff' that at present you can't do?
> Referencing controllers from production.rb being the obvious case.
>
> Finally, as we'd no longer be preloading ApplicationController, is
> there anything which might be relying on this?
>
> I'm definitely keen on fixing it up, I'm just worried that a torrent
> of empty +1s may swamp any back-and-forth about the risks and benefits
> to making the change.
>
> [1] I think you're crazy to be running on edge right now, but some
> people like it :)
>
> --
> Cheers
>
> Koz
>
> >
>
--
-- Assaf
E. James O'Kelly
something that has bugged me, just never got around to ticketing it.
---
Pei Mei
(James O'Kelly)
ara.t.howard
sounds like a good move in general, but i don't know if it's worth it
without really considering the goal of the original
ApplicationController and how it basically falls down on the job.
let me explain: it's bothered me to no end that rails doesn't really
support any sort of centralized view of what the hell and application
does, especially for a developer inheriting a project.
application.rb is a nice spot not only for sharing behavior across
controllers, but also for monkey patching junk in in a way that
people are likely to notice it. however, we have no such equivalent
for models or the app as a whole - only views share something
similar. lately i've been doing this
app/api.rb
and putting all my config, all my thick model stuff, and all the high
level stuff for my app that people should be able to use. i won't go
into the details other than to point out i think we sorely need
something like
App.google_ad_client 'pub-1234'
App.create_user email, password
App.model do
default 'rating' => 42
end
so a central set of base classes for models, controllers, views and
also config. the reason i mention this is that 'application.rb' is a
*perfect* name for such a file. of course i can't use it so i use
api.rb, site.rb, or sometimes app.rb. none of them feels right
however. so my basic concern is not so much that 'application.rb' is
named poorly, rather it is that it does very little to aid adding a
central entry point for developers which, imho, something named that
way should.
seems worth considering since another location for application.rb
with different roles, including that if setting up a base controller,
might suggest an all together different migration strategy.
kind regards.
a @ http://drawohara.com/
--
sleep is the best meditation.
h.h. the 14th dalai lama
Xavier Noria
> let me explain: it's bothered me to no end that rails doesn't really
> support any sort of centralized view of what the hell and application
> does, especially for a developer inheriting a project.
> application.rb is a nice spot not only for sharing behavior across
> controllers, but also for monkey patching junk in in a way that
> people are likely to notice it.
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.
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.
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.
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.
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.
-- fxn
ara.t.howard
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.
Xavier Noria
> a great example is
>
> ApplicationModel < ActiveRecord::Base
> before_save do |record|
> record.updated_by = ApplicationController.current if
> record.respond_to? 'updated_at'
> end
> end
Yes, custom macros would go there as well... it has use cases.
> 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.
I think it would be expected to emulate what's done with
ApplicationController. That is, the rails generator would write
app/models/application_model.rb
with something like
class ApplicationModel < ActiveRecord::Base
# Stuff common to your models comes here.
end
and the model generator would output something like this
class User < ApplicationModel
end
Active Record would understand ApplicationModel is abstract as a hard-
coded builtin assumption.
-- fxn
ara.t.howard
On Jan 13, 2008, at 2:00 PM, Xavier Noria wrote:
>
> I think it would be expected to emulate what's done with
> ApplicationController. That is, the rails generator would write
>
> app/models/application_model.rb
>
> with something like
>
> class ApplicationModel < ActiveRecord::Base
> # Stuff common to your models comes here.
> end
>
> and the model generator would output something like this
>
> class User < ApplicationModel
> end
>
> Active Record would understand ApplicationModel is abstract as a hard-
> coded builtin assumption.
>
yep that's a start. i'd personally push harder though - i would love
to run rdoc over my rails app and see sections for
Application::Controller
Application::Model
Application::View
Application::Config
Application::RubyExt
etc. the rails structure is currently a tree without a root -
without a single entry point or logical 'top' - add to that the
beautiful and dangerous fact that you can hack any class anywhere and
you end up with a mess. the current structure organizes mvc, but not
applications imho, either logically or physically. helpers might be
the only exception, but of course they are simply procedural in
nature having no state to leverage and not a wide enough domain.
kind regards
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
Ryan Bigg
For example if you tell someone to "go into the blogs controller" they
will look for a file called "blogs_controller" in the app/controllers
directory instinctively. If you tell someone to "look for the
application controller", they'll instinctively look for
application_controller.rb, and then realise it's actually
application.rb.
So what if a few thousand websites have to rename ONE file. It's no
worse than the changes within files Rails 2.0 caused (i.e. routing &
session)
Gabe da Silveira
> I still find it confusing that the class ApplicationController resides
> in a file called application.rb, not following the class/file naming
> convention used elsewhere.
>
> But I also find it confusing that it's called ApplicationController to
> begin with, given that it doesn't expose any actions and I never route
> to it. It's simply a base class for application-wide functionality.
> So why not call it Application?
>
> Controller superclasses don't have to use the Controller prefix, as
> evident by ApplicationController::Base.
I think Assaf hit the nail on the head. Doing this would keep the
controller namespace completely clean (ie. someone could have
ApplicationController if they want, even though that would probably be
a bad idea). Granted, it might be too much pain since every single
controller file would then have to change. Maybe Rails has matured to
the point where this kind of fix is simply too painful relative to the
benefit?
Pratik
> Maybe Rails has matured to
> the point where this kind of fix is simply too painful relative to the
> benefit?
My feelings exactly. That was my point to post +1 to the ticket. I
really fail to see the benefits of this change. application.rb used to
be called abstract_controller.rb - so we've already been on that road
before.
--
Cheers!
- Pratik
http://m.onkey.org
Michael Koziarski
> really fail to see the benefits of this change. application.rb used to
> be called abstract_controller.rb - so we've already been on that road
> before.
Well, what are the other benefits of having a consistenly named
parent controller. Consistency is great, but are there features that
are easier with this?
For example, are there any changes for plugin authors? Does this
make *something* they do any easier?
--
Cheers
Koz
Assaf Arkin
>
> > My feelings exactly. That was my point to post +1 to the ticket. I
> > really fail to see the benefits of this change. application.rb used to
> > be called abstract_controller.rb - so we've already been on that road
> > before.
>
> Well, what are the other benefits of having a consistenly named
> parent controller. Consistency is great, but are there features that
> are easier with this?
I think for a framework, consistency is a goal in itself, it's one key
feature developers look for in a framework. For one, Application is
not a controller, since no actions are directed at it, merely removing
that confusion is a benefit.
Ruby allows you to alias classes (ApplicationController =
Application), so it will be interesting to do a backward compatible
switch and survey how many plugins can handle it.
Assaf
Sven Fuchs
> parent controller. Consistency is great, but are there features that
> are easier with this?
>
> For example, are there any changes for plugin authors? Does this
> make *something* they do any easier?
This actually would make authoring plugins that "monkeypatch"
application controllers easier, yes.
Right now one has to jump through hoops to do that (and, above all,
know which ones and how).
"monkeypatch" in quotes as this is a recommended (and successfull)
practice for quite some apps out there.
So, yes, there's a real benefit.
--
sven fuchs sven...@artweb-design.de
artweb design http://www.artweb-design.de
grünberger 65 + 49 (0) 30 - 47 98 69 96 (phone)
d-10245 berlin + 49 (0) 171 - 35 20 38 4 (mobile)
Pratik
Michael Schuerig
> > For example, are there any changes for plugin authors? Does this
> > make *something* they do any easier?
>
> This actually would make authoring plugins that "monkeypatch"
> application controllers easier, yes.
>
> Right now one has to jump through hoops to do that (and, above all,
> know which ones and how).
Would you mind to elaborate? I don't understand what you mean, but I'm
curious.
Michael
--
Michael Schuerig
mailto:mic...@schuerig.de
http://www.schuerig.de/michael/
Sven Fuchs
> On Wednesday 16 January 2008, Sven Fuchs wrote:
>>> For example, are there any changes for plugin authors? Does this
>>> make *something* they do any easier?
>>
>> This actually would make authoring plugins that "monkeypatch"
>> application controllers easier, yes.
>>
>> Right now one has to jump through hoops to do that (and, above all,
>> know which ones and how).
>
> Would you mind to elaborate? I don't understand what you mean, but I'm
> curious.
You can't alter an app controller class during plugin load stage like
you can, e.g., alter a model class because Application hasn't loaded
yet at this stage and autoloading will choke because
ApplicationController can't be found automatically (due to the file
naming convention breakage application.rb).
The "right" hoop to jump through might be to just require
application.rb manually from the plugin. A "wrong" hoop might be to
postpone controller class patching to e.g. config.to_prepare or
something (which seems to work on many setups but miserably break on
some due to class reloading issues).
E.g. in Mephistoland there are lots of examples of situations where
one wants to add a certain feature through a plugin.
A different path around this issue (rather than renaming
application.rb) could be to load Application before the plugin loading
stage by default.
Did that answer your question?
ara.t.howard
On Jan 16, 2008, at 7:24 AM, Sven Fuchs wrote:
> Did that answer your question?
and +2 from me.
share your knowledge. it's a way to achieve immortality.
Pratik
> This actually would make authoring plugins that "monkeypatch"
> application controllers easier, yes.
>
> Right now one has to jump through hoops to do that (and, above all,
> know which ones and how).
>
> "monkeypatch" in quotes as this is a recommended (and successfull)
> practice for quite some apps out there.
>
> So, yes, there's a real benefit.
Could you explain on that part ?
Btw, I like the idea of renaming it to Application instead of
ApplicationController, in case we *must* change it.
Xavier Noria
> Btw, I like the idea of renaming it to Application instead of
> ApplicationController, in case we *must* change it.
Application is too generic in my opinion. That is a file related to
controllers, not to the application as a whole.
We have application_helper.rb, and I am working on
application_model.rb as per some mails in the middle of the thread. I
think application_controller.rb is a natural change.
The prefix "Application" would convey a sense of root (abstract) class
per layer.
-- fxn
Sven Fuchs
>> So, yes, there's a real benefit.
> Could you explain on that part ?
Just did that in the other mail. http://www.ruby-forum.com/topic/138628#618338
Please let me know if that doesn't answer the question.
> Btw, I like the idea of renaming it to Application instead of
> ApplicationController, in case we *must* change it.
Personally I feel that Application is too general as this class only
acts as a base class for controllers. So that might be a misleading
naming.
ara.t.howard
On Jan 16, 2008, at 8:33 AM, Pratik wrote:
>
> Btw, I like the idea of renaming it to Application instead of
> ApplicationController, in case we *must* change it.
>
Application::Controller
Application::Model
Application::View
Applcation::Config
we need all these - why not just see into the future a tiny bit and
carve out a namespace instead of continuing to dump billions of
consts into the top-level?
regards
Michael Schuerig
> Did that answer your question?
Yes, thanks.
Xavier Noria
> We have application_helper.rb, and I am working on
> application_model.rb as per some mails in the middle of the thread.
OK, here we go!!!
http://dev.rubyonrails.org/ticket/10832
-- fxn
Rick DeNatale
>
>
> On Jan 16, 2008, at 8:33 AM, Pratik wrote:
>
> >
> > Btw, I like the idea of renaming it to Application instead of
> > ApplicationController, in case we *must* change it.
> >
>
> Application::Controller
> Application::Model
> Application::View
> Applcation::Config
I kind of like this idea, although my gut instinct tells me that it
might want to follow the existing module hierarchy.
class Application::ActionController < ::ActionController::Base
class Application::ActiveRecord::Base < ::ActiveRecord::Base
class Application::ActionView::Base < ::ActionView::Base
I'm not sure what Config is, TMail::Config?
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
Trevor Turk
> I'm definitely keen on fixing it up, I'm just worried that a torrent
> of empty +1s may swamp any back-and-forth about the risks and benefits
> to making the change.
model "application" with a controller "application_controller" etc? I
like the idea of doing some global namespacing or something so that
wouldn't be an issue.
- Trevor
Rob Sanheim
Jeremy McAnally
EigenClass::ClassFactory::ApplicationFactory::Application::ApplicationSpace::MyApplication::Factories::ModelFactory::Interfaces::IModel
< EigenClass::Namespace::Rails::ApplicationAPI::Abstract::Interface::Models::ActiveRecord::Base
Then your models can do MyModel < IModel.
Much cleaner.
--Jeremy
--
http://www.jeremymcanally.com/
My books:
Ruby in Practice
http://www.manning.com/mcanally/
My free Ruby e-book
http://www.humblelittlerubybook.com/
My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/
Pratik
I'm not really satisfied with this use case. From plugins, you're much
more likely to monkeypatch ActionController::Base and much more less
likely to monkeypacth ApplicationController. In fact, if plugin is
monkeypatching ActionController::Base, it's a lot easier to override
it in ApplicationController. But again, I might be missing a point
here. So please feel free to correct me !
Thanks.
On Jan 16, 12:33 pm, Sven Fuchs <svenfu...@artweb-design.de> wrote:
> Am 16.01.2008 um 05:29 schrieb Michael Koziarski:
>
> > parent controller. Consistency is great, but are there features that
> > are easier with this?
>
> > For example, are there any changes for plugin authors? Does this
> > make *something* they do any easier?
>
> This actually would make authoring plugins that "monkeypatch"
> application controllers easier, yes.
>
> Right now one has to jump through hoops to do that (and, above all,
> know which ones and how).
>
> "monkeypatch" in quotes as this is a recommended (and successfull)
> practice for quite some apps out there.
>
> So, yes, there's a real benefit.
>
> --
Sven Fuchs
I guess, a distinction might help.
Most Rails plugins target the framework as a tool to build
applications. E.g. all acts_as_* plugins live on this level. But the
same strategy of "let people work out solutions in plugin land" that
has been so wildly successful for Rails has been adopted to
applications like Mephisto. As such there are plugins that don't
target Rails itself but specific applications. And the same success
story continues to work on this level, too.
I totally agree that for framework level plugins it makes sense to
alter ActionController::Base. But that doesn't apply to plugins that
target an application.
Examples for this usecase are additions to Mephisto like pagination of
article lists, custom spam protection mechanisms, additional archives
and stuff like that (i.e. features that are intentionally left out of
Mephisto and pushed into Mephisto plugin land). These need to amend
MephistoController and can't be done just working on
ActionController::Base. The same thing applies to many application
level controller plugins.
--
sven fuchs sven...@artweb-design.de
ara.t.howard
On Jan 16, 2008, at 10:41 AM, Rick DeNatale wrote:
> I kind of like this idea, although my gut instinct tells me that it
> might want to follow the existing module hierarchy.
>
> class Application::ActionController < ::ActionController::Base
> class Application::ActiveRecord::Base < ::ActiveRecord::Base
> class Application::ActionView::Base < ::ActionView::Base
yeah that makes more sense
>
> I'm not sure what Config is, TMail::Config?
>
Application.configure 'google_ad_client' => '1234'
etc. some sort of openobject/openstruct to put application specific
'globals' into. i think it's crappy that there is no namespace for
this stuff.
cheers.
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
ara.t.howard
On Jan 17, 2008, at 12:01 AM, Rob Sanheim wrote:
> All these things smell like premature generalization to me...
google for
'rails how do i setup created_by'
and imagine that we had
Application::Model
and the normal filter chain
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
ara.t.howard
On Jan 17, 2008, at 10:06 AM, Jeremy McAnally wrote:
> No, no, no! You see, if you do that then it's one step to
> EigenClass::ClassFactory::ApplicationFactory::Application::Application
> Space::MyApplication::Factories::ModelFactory::Interfaces::IModel
> <
> EigenClass::Namespace::Rails::ApplicationAPI::Abstract::Interface::Mod
> els::ActiveRecord::Base
>
> Then your models can do MyModel < IModel.
>
> Much cleaner.
>
possibly
ApplicationController
ApplicationModel
are just as good. it's the functionality, not impl that i'd like to
see.
it is not enough to be compassionate. you must act.