application.rb -> application_controller.rb

Sven_Fuchs · January 16, 2008, 4:00pm

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.

Michael_Schuerig1 · January 16, 2008, 4:53pm

Yes, thanks.

Michael

a111 · January 16, 2008, 4:54pm

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

a @ http://codeforpeople.com/

fxn · January 16, 2008, 5:08pm

OK, here we go!!!

http://dev.rubyonrails.org/ticket/10832

-- fxn

Rick_DeNatale · January 16, 2008, 5:41pm

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?

Trevor_Turk · January 17, 2008, 3:14am

Please excuse my silly question, but what if people want to have a 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 · January 17, 2008, 7:01am

All these things smell like premature generalization to me...

- Rob

Jeremy_McAnally · January 17, 2008, 5:06pm

No, no, no! You see, if you do that then it's one step to 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

Pratik1 · January 17, 2008, 8:45pm

Sevn,

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.

Sven_Fuchs · January 17, 2008, 10:32pm

Wow, you managed to say "monkeypatch" three times in two sentences

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.

a111 · January 18, 2008, 11:06pm

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