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 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 --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 12, 2008 3:26 PM, Michael Koziarski <michael@koziarski.com> wrote:> > 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/10570I 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 http://labnotes.org --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
I would love to hear any possible disadvantages. This has always something that has bugged me, just never got around to ticketing it. --- Pei Mei (James O''Kelly) --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 12, 2008, at 4:26 PM, Michael Koziarski wrote:> 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 > > 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 :)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 --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 13, 2008, at 6:15 AM, ara.t.howard wrote:> 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 --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 13, 2008, at 6:21 PM, ara.t.howard wrote:> a great example is > > ApplicationModel < ActiveRecord::Base > before_save do |record| > record.updated_by = ApplicationController.current if > record.respond_to? ''updated_at'' > end > endYes, 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 --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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 a @ http://codeforpeople.com/ -- we can deny everything, except that we have the possibility of being better. simply reflect on that. 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
I would prefer it to follow the layout of all the other controllers. 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) --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 12, 2008 3:56 PM, Assaf Arkin <assaf@labnotes.org> wrote:> 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? --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 15, 2008 5:45 PM, Gabe da Silveira <gabriel.d@gmail.com> wrote:> 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 --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> 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? For example, are there any changes for plugin authors? Does this make *something* they do any easier? -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 15, 2008 8:29 PM, Michael Koziarski <michael@koziarski.com> wrote:> > > 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> > For example, are there any changes for plugin authors? Does this > make *something* they do any easier? > > > > -- > Cheers > > Koz--~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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 svenfuchs@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) --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
A little correction. I''m the "-1" guy. "+" was a typo :) On Jan 15, 2008 5:48 PM, Pratik <pratiknaik@gmail.com> wrote:> On Jan 15, 2008 5:45 PM, Gabe da Silveira <gabriel.d@gmail.com> wrote: > > 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 >-- Cheers! - Pratik http://m.onkey.org --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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. Michael -- Michael Schuerig mailto:michael@schuerig.de http://www.schuerig.de/michael/ --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Am 16.01.2008 um 14:54 schrieb Michael Schuerig:> 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? -- sven fuchs svenfuchs@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) --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 16, 2008, at 7:24 AM, Sven Fuchs wrote:> Did that answer your question?and +2 from me. 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 16, 2008 12:33 PM, Sven Fuchs <svenfuchs@artweb-design.de> wrote:> 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. -- Cheers! - Pratik http://m.onkey.org --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 16, 2008, at 4:33 PM, Pratik wrote:> 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 --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Am 16.01.2008 um 16:33 schrieb Pratik:>> 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. -- sven fuchs svenfuchs@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) --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Wednesday 16 January 2008, Sven Fuchs wrote:> Did that answer your question?Yes, thanks. Michael -- Michael Schuerig mailto:michael@schuerig.de http://www.schuerig.de/michael/ --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 16, 2008, at 4:54 PM, Xavier Noria wrote:> 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 --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 1/16/08, ara.t.howard <ara.t.howard@gmail.com> wrote:> > > 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::ConfigI 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/ --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 12, 5:26 pm, "Michael Koziarski" <mich...@koziarski.com> wrote:> 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.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 --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 16, 2008 12:41 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:> > On 1/16/08, ara.t.howard <ara.t.howard@gmail.com> wrote: > > > > > > 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 RubyAll these things smell like premature generalization to me... - Rob http://robsanheim.com --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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 On Jan 17, 2008 2:01 AM, Rob Sanheim <rsanheim@gmail.com> wrote:> > On Jan 16, 2008 12:41 PM, Rick DeNatale <rick.denatale@gmail.com> wrote: > > > > On 1/16/08, ara.t.howard <ara.t.howard@gmail.com> wrote: > > > > > > > > > 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 > > All these things smell like premature generalization to me... > > - Rob > > http://robsanheim.com > > > > >-- 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/ --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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. 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 svenfu...@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)--~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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. Am 17.01.2008 um 21:45 schrieb Pratik:> > 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. > > 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 svenfu...@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) > >-- sven fuchs svenfuchs@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) --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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::Baseyeah 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. a @ http://codeforpeople.com/ -- we can deny everything, except that we have the possibility of being better. simply reflect on that. 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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 a @ http://codeforpeople.com/ -- we can deny everything, except that we have the possibility of being better. simply reflect on that. 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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. a @ http://codeforpeople.com/ -- it is not enough to be compassionate. you must act. 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---