I''ve written an article suggesting some radical changes to the Rails directory structure for Rails 2.0 and am curious to know the core team''s thoughts about it: http://wiseheartdesign.com/2007/6/15/better-modularization-for-rails-2-0/ -- John Long http://wiseheartdesign.com http://radiantcms.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 6/15/07, John W. Long <johnwlong2000@gmail.com> wrote:> > > I''ve written an article suggesting some radical changes to the Rails > directory structure for Rails 2.0 and am curious to know the core > team''s thoughts about it:Nice article, short and to the point. While the benefits are certainly recognizable, I, for one, would find slightly shocking to have a directory like this: blog/ _config.rb _routes.rb blog_controller.rb blog_helper.rb blog_index.rhtml blog_archive.rhtml blog_post.rhtml comment.rb comment_migrations.rb comments_controller.rb comments_helper.rb comments_view.rhtml post.rb post_migrations.rb I''ve been spoiled by the clean separation in Rails and I''d hate to go back to spaghetti directory structure. I imagine that most of its users would feel the same, too. --~--~---------~--~----~------------~-------~--~----~ 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''ve written an article suggesting some radical changes to the Rails > directory structure for Rails 2.0 and am curious to know the core > team''s thoughts about it:Thanks for thinking about this John, but I don''t see Rails adopting something along those lines right now. We can definitely do more to improve high-level reuse for the sub-set of users who need it, but it probably won''t be setting the tone quite as dramatically as this. I much prefer to have things divided by type when I''m just working on a single application. And anything that includes prefixing underscores is a visual non-starter for me ;). --~--~---------~--~----~------------~-------~--~----~ 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 6/15/07, Mislav Marohnić <mislav.marohnic@gmail.com> wrote:> On 6/15/07, John W. Long <johnwlong2000@gmail.com> wrote: > > > > I've written an article suggesting some radical changes to the Rails > > directory structure for Rails 2.0 and am curious to know the core > > team's thoughts about it: > > Nice article, short and to the point. > > While the benefits are certainly recognizable, I, for one, would find > slightly shocking to have a directory like this: > blog/ > _config.rb > _routes.rb > blog_controller.rb > blog_helper.rb > > blog_index.rhtml > blog_archive.rhtml > blog_post.rhtml > comment.rb > comment_migrations.rb > comments_controller.rb > comments_helper.rb > comments_view.rhtml > post.rb > > post_migrations.rb > > I've been spoiled by the clean separation in Rails and I'd hate to go back > to spaghetti directory structure. I imagine that most of its users would > feel the same, too.Some of my larger plugins tend to look like that, though. It feels wrong, I want to add directories to separate models and controllers. Though ultimately, textmate makes it so I don't have to care that much about the actual directory structure. -- Rick Olson http://lighthouseapp.com http://weblog.techno-weenie.net http://mephistoblog.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 -~----------~----~----~----~------~----~------~--~---
I like the writeup, but I don't see it as a big enough benefit to justify the pain of changing it. Both structures have their benefits. If one was clearly superior then I say damn the pain and change it, but in this case it seems more like an arbitrary choice. Rails chose the MVC structure and Django chose the component structure. In a way it reflects the philosophies of the two frameworks. I like this structure much better than Rails' components though. Maybe this type of structure could be used for a lighter-weight version of components for Rails 2.0. At first glance it would appear ugly to have two different kinds of file organization, but maybe there's a strong use case for lightweight components? At any rate, it's great to see this kind of fresh thinking. On 6/15/07, Rick Olson <technoweenie@gmail.com> wrote:> On 6/15/07, Mislav Marohnić <mislav.marohnic@gmail.com> wrote: > > On 6/15/07, John W. Long <johnwlong2000@gmail.com> wrote: > > > > > > I've written an article suggesting some radical changes to the Rails > > > directory structure for Rails 2.0 and am curious to know the core > > > team's thoughts about it: > > > > Nice article, short and to the point. > > > > While the benefits are certainly recognizable, I, for one, would find > > slightly shocking to have a directory like this: > > blog/ > > _config.rb > > _routes.rb > > blog_controller.rb > > blog_helper.rb > > > > blog_index.rhtml > > blog_archive.rhtml > > blog_post.rhtml > > comment.rb > > comment_migrations.rb > > comments_controller.rb > > comments_helper.rb > > comments_view.rhtml > > post.rb > > > > post_migrations.rb > > > > I've been spoiled by the clean separation in Rails and I'd hate to go back > > to spaghetti directory structure. I imagine that most of its users would > > feel the same, too. > > Some of my larger plugins tend to look like that, though. It feels > wrong, I want to add directories to separate models and controllers. > Though ultimately, textmate makes it so I don't have to care that much > about the actual directory structure. > > -- > Rick Olson > http://lighthouseapp.com > http://weblog.techno-weenie.net > http://mephistoblog.com > > > >-- Gabe da Silveira http://darwinweb.net --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
+1 "_foo" == :-( b DHH wrote:>> I''ve written an article suggesting some radical changes to the Rails >> directory structure for Rails 2.0 and am curious to know the core >> team''s thoughts about it: > > Thanks for thinking about this John, but I don''t see Rails adopting > something along those lines right now. We can definitely do more to > improve high-level reuse for the sub-set of users who need it, but it > probably won''t be setting the tone quite as dramatically as this. I > much prefer to have things divided by type when I''m just working on a > single application. And anything that includes prefixing underscores > is a visual non-starter for me ;). > > > > >--~--~---------~--~----~------------~-------~--~----~ 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 Jun 15, 6:29 pm, DHH <david.heineme...@gmail.com> wrote:> Thanks for thinking about this John, but I don''t see Rails adopting > something along those lines right now. We can definitely do more to > improve high-level reuse for the sub-set of users who need it, but it > probably won''t be setting the tone quite as dramatically as this. I > much prefer to have things divided by type when I''m just working on a > single application.Help me out here. I''m not sure I understand why type is better. Setting the modularization argument aside grouping your application into logical parts seems like a win to me.> And anything that includes prefixing underscores > is a visual non-starter for me ;).Humor me for a minute here. The underscores aren''t the critical part of the idea. -- John Long http://wiseheartdesign.com http://radiantcms.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 Fri, Jun 15, 2007 at 11:46:34PM -0000, John W. Long wrote:> > On Jun 15, 6:29 pm, DHH <david.heineme...@gmail.com> wrote: > > Thanks for thinking about this John, but I don''t see Rails adopting > > something along those lines right now. We can definitely do more to > > improve high-level reuse for the sub-set of users who need it, but it > > probably won''t be setting the tone quite as dramatically as this. I > > much prefer to have things divided by type when I''m just working on a > > single application. > > Help me out here. I''m not sure I understand why type is better. > Setting the modularization argument aside grouping your application > into logical parts seems like a win to me.The thing that immediately struck me about this proposal was the interdependencies between the different parts of the application. The example in the original post showed several (of what I presume are) models in the app/blog subdirectory, but I''d expect that the models and controllers in that subdir also require the model in the app/account subdirectory. If you wanted to give someone else the app/blog subdirectory to use in their application, then some degree of scaffolding or similar would be required in the user model to make it work. I''m curious if django has a solution to this problem? Usually, in my applications, there would almost always be a single directory that had all of the models and controllers, since there''s almost always a dependency chain that links all of them together. As I understand it, the purpose of the rearrangement would be to support making it trivial to carve out subsets of a Rails application for re-use, but in my experience, the directory structure is the *last* thing you need to be worrying about. There are many, many more important things to decide on before concerning yourself with how many different directories you need to copy files out of. If your goal is only to allow people to structure plugins in a more Rails-like manner, rather than assisting so much in the *extraction* of the plugins, then I would suggest that adding vendor/plugins/<plugin_name>/app?/{models,controllers,helpers,views} to the search paths would achieve that aim without requiring what is a fairly fundamental change to the way in which all Rails applications are structured. For myself, I think that the proposed change is an aesthetic loss, but that may simply be familiarity with the existing layout talking. - Matt -- I killed init(8) and all I got was this lousy kernel panic. -- Graham Reed, in the Monastery --~--~---------~--~----~------------~-------~--~----~ 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''ve written an article suggesting some radical changes to the Rails > directory structure for Rails 2.0 and am curious to know the core > team''s thoughts about it: > > http://wiseheartdesign.com/2007/6/15/better-modularization-for-rails-2-0/Leaving aside the asthetic issues, and the high cost to tooling and books of changing the application layout, I''m curious about the whole rationale. "One of the primary hinderances of the present Rails architecture to modularization is the directory structure." Is this even true? We have configurable load paths, controller paths, and view paths. I simply can''t see how the directory structure is even on the list of the top ten problems to ''modularization'' of a rails application. -- 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 -~----------~----~----~----~------~----~------~--~---
> Is this even true?I''d submit that, yes, it is. The best way that I''ve found of sharing entire "slices" of an application, is simply pluginize the whole thing. Which is rather bothersome. But, in that case, I simply have an svn:external (or in some cases just a symlink) pointing to the plugin. To do that without pluginizing, using the current directory structure, is impractical. That being said though, I don''t think thats enough reason to justify such a change. Others have already mentioned the appropriate reasons as to why its not. Tyler On 6/15/07, Michael Koziarski <michael@koziarski.com> wrote:> > > > I''ve written an article suggesting some radical changes to the Rails > > directory structure for Rails 2.0 and am curious to know the core > > team''s thoughts about it: > > > > > http://wiseheartdesign.com/2007/6/15/better-modularization-for-rails-2-0/ > > Leaving aside the asthetic issues, and the high cost to tooling and > books of changing the application layout, I''m curious about the whole > rationale. > > "One of the primary hinderances of the present Rails architecture to > modularization is the directory structure." > > Is this even true? We have configurable load paths, controller > paths, and view paths. I simply can''t see how the directory structure > is even on the list of the top ten problems to ''modularization'' of a > rails application. > > -- > 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 -~----------~----~----~----~------~----~------~--~---
I agree as well. It''s only ONE problem, but it''s a big one. Distribution, upgrades, and even just seeing what files came from where. Generators don''t solve it, and plugins just seem wrong. The closest thing would be Components, but of course they have their own issues. The other problems may or may not be more significant. Granted, you can''t rip out the average controller from an arbitrary app and re-use it, but there''s no reason you can''t have loosely coupled "apps" running under the same memory footprint sharing nothing more than a common login. I started to write more on the subject and it turned into a whole article: http://darwinweb.net/article/Modular_Development_On_Rails What do you think? On 6/16/07, Tyler McMullen <tbmcmullen@gmail.com> wrote:> > Is this even true? > > I''d submit that, yes, it is. The best way that I''ve found of sharing entire > "slices" of an application, is simply pluginize the whole thing. Which is > rather bothersome. But, in that case, I simply have an svn:external (or in > some cases just a symlink) pointing to the plugin. To do that without > pluginizing, using the current directory structure, is impractical. > > That being said though, I don''t think thats enough reason to justify such a > change. Others have already mentioned the appropriate reasons as to why its > not. > > Tyler > > > On 6/15/07, Michael Koziarski <michael@koziarski.com> wrote: > > > > > I''ve written an article suggesting some radical changes to the Rails > > > directory structure for Rails 2.0 and am curious to know the core > > > team''s thoughts about it: > > > > > > > http://wiseheartdesign.com/2007/6/15/better-modularization-for-rails-2-0/ > > > > Leaving aside the asthetic issues, and the high cost to tooling and > > books of changing the application layout, I''m curious about the whole > > rationale. > > > > "One of the primary hinderances of the present Rails architecture to > > modularization is the directory structure." > > > > Is this even true? We have configurable load paths, controller > > paths, and view paths. I simply can''t see how the directory structure > > is even on the list of the top ten problems to ''modularization'' of a > > rails application. > > > > -- > > Cheers > > > > Koz > > > > > > > > >-- Gabe da Silveira http://darwinweb.net --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
It is if that is your viewpoint. Fundamentally the object map is a network, not a tree. So a directory hierarchy can only ever show one viewpoint. And the current one is as good a compromise as any. Perhaps a solution is a generator that can creates a different view using symbolic links? Either that or a semantic filesystem... :-) NeilW On Jun 16, 3:45 am, "Michael Koziarski" <mich...@koziarski.com> wrote:> Is this even true? We have configurable load paths, controller--~--~---------~--~----~------------~-------~--~----~ 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 Jun 15, 10:45 pm, "Michael Koziarski" <mich...@koziarski.com> wrote:> Is this even true? We have configurable load paths, controller > paths, and view paths. I simply can''t see how the directory structure > is even on the list of the top ten problems to ''modularization'' of a > rails application.My experience with building an extension system for Radiant tells me that it is. Radiant extensions provide an app directory with places for controllers, views, and models--just like Rails--and the whole thing seems extremely heavyweight. Granted I can easily fix the layout for the Radiant extension system, but that would kind of defeat the purpose. Radiant extensions are supposed to look like mini-rails apps. I believe the whole thing reveals a systemic problem with the way the Rails directory structure was designed. A bold claim, I know, but I believe it''s true. Again, what exactly is the point of organizing files by type? Our applications have logical structure, why not reflect that in directory layout? Perhaps the example laid out in my article is a bit extreme. I''d see it as a win if we just moved to a directory per related controller, model, and views: app/ application/ application_controller.rb application_layout.rhtml accounts/ account.rb accounts_controller.rb accounts_helper.rb accounts_edit.rhtml accounts_login.rhtml accounts_signup.rhtml posts/ post.rb posts_controller.rb posts_helper.rb posts_index.rhtml posts_archive.rhtml posts_post.rhtml comments/ comment.rb comments_controller.rb comments_helper.rb comments_list.rhtml Is that not 10 times cleaner and easier to navigate? Now I can `mate app/comments` to work on a single controller and related views. Please, set the issues of backwards compatibility aside or personal preference and argue with merit alone. -- John Long http://wiseheartdesign.com http://radiantcms.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 -~----------~----~----~----~------~----~------~--~---
Because of "configurable load paths, controller paths, and view paths", I believe that what John Long is proposing is already possible. It would just take some ingenuity and configuration effort. So I really don''t see the sense in lobbying for *everyone* using Rails to change over to that alternate directory structure. Cheers, Obie On 6/16/07, John W. Long <johnwlong2000@gmail.com> wrote:> > On Jun 15, 10:45 pm, "Michael Koziarski" <mich...@koziarski.com> > wrote: > > Is this even true? We have configurable load paths, controller > > paths, and view paths. I simply can''t see how the directory structure > > is even on the list of the top ten problems to ''modularization'' of a > > rails application. > > My experience with building an extension system for Radiant tells me > that it is. Radiant extensions provide an app directory with places > for controllers, views, and models--just like Rails--and the whole > thing seems extremely heavyweight. > > Granted I can easily fix the layout for the Radiant extension system, > but that would kind of defeat the purpose. Radiant extensions are > supposed to look like mini-rails apps. > > I believe the whole thing reveals a systemic problem with the way the > Rails directory structure was designed. A bold claim, I know, but I > believe it''s true. > > Again, what exactly is the point of organizing files by type? Our > applications have logical structure, why not reflect that in directory > layout? > > Perhaps the example laid out in my article is a bit extreme. I''d see > it as a win if we just moved to a directory per related controller, > model, and views: > > app/ > application/ > application_controller.rb > application_layout.rhtml > accounts/ > account.rb > accounts_controller.rb > accounts_helper.rb > accounts_edit.rhtml > accounts_login.rhtml > accounts_signup.rhtml > posts/ > post.rb > posts_controller.rb > posts_helper.rb > posts_index.rhtml > posts_archive.rhtml > posts_post.rhtml > comments/ > comment.rb > comments_controller.rb > comments_helper.rb > comments_list.rhtml > > Is that not 10 times cleaner and easier to navigate? Now I can `mate > app/comments` to work on a single controller and related views. > > Please, set the issues of backwards compatibility aside or personal > preference and argue with merit alone. > > -- > John Long > http://wiseheartdesign.com > http://radiantcms.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 16 Jun 2007, at 16:51, John W. Long wrote:> > > Perhaps the example laid out in my article is a bit extreme. I''d see > it as a win if we just moved to a directory per related controller, > model, and views: > >[snipped example]> > Is that not 10 times cleaner and easier to navigate? Now I can `mate > app/comments` to work on a single controller and related views.Sure that''s nice and easy to look at, but it rather assumes that you can take each model and assign it to a controller. The rails apps I work on would not fit so easily into that schema: many models have dependencies on other models, many controllers pull together several models. A lot of our models would have to either somehow live in 3 different places or I''d somehow have to arbitrarily pick one controller/component as the ''master'' one for that model. Other models don''t have corresponding controllers at all. Fred
On Jun 16, 1:27 pm, Frederick Cheung <frederick.che...@gmail.com> wrote:> On 16 Jun 2007, at 16:51, John W. Long wrote: > > Is that not 10 times cleaner and easier to navigate? Now I can `mate > > app/comments` to work on a single controller and related views. > > Sure that''s nice and easy to look at, but it rather assumes that you > can take each model and assign it to a controller. The rails apps I > work on would not fit so easily into that schema: many models have > dependencies on other models, many controllers pull together several > models. A lot of our models would have to either somehow live in 3 > different places or I''d somehow have to arbitrarily pick one > controller/component as the ''master'' one for that model. Other models > don''t have corresponding controllers at all.That''s not necessarily true. For those models you could drop them in the "app/application" folder with "application_controller.rb" or even in a standard "shared" directory. There are any number of ways of doing it and keeping it clean. -- John Long http://wiseheartdesign.com http://radiantcms.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 -~----------~----~----~----~------~----~------~--~---
There is a definite benefit to being able to look at all the models or controllers for an application together, or all the controllers. You might convince me that your idea is BETTER, but you won''t convince me that it is universally better, or that organization by type is somehow redundant and carries semantic benefit. When you are working on radiant extensions of course it seems heavyweight because you are talking about modular pieces of functionality that are supposed to be tight and contained by design. However Rails was designed to build monolithic applications, and when you 10 heavily interdependent controllers backed by 20 models, you''re getting a good number of files per directory. Breaking them down into modules may not be straightforward at all. If models are used evenly by many controllers where do they go? Suddenly you find yourself creating many modules just so the hierarchy is logical, and you end up with the converse problem: that you have too many modules, none of which are re-usable, when you could have everything in a single controllers and models directory. I totally understand how a Radiant extension just feels bloated with all those directories, so I support some kind lighter-weight packaging such as you propose. I think Obie is on the right track that we are close to being able to do this already, but it will definitely need some optimization as we can''t just go filling up the view_paths and controller paths willy-nilly everytime we add a module. On Jun 16, 9:51 am, "John W. Long" <johnwlong2...@gmail.com> wrote:> Again, what exactly is the point of organizing files by type? Our > applications have logical structure, why not reflect that in directory > layout?--~--~---------~--~----~------------~-------~--~----~ 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 experience with building an extension system for Radiant tells me > that it is. Radiant extensions provide an app directory with places > for controllers, views, and models--just like Rails--and the whole > thing seems extremely heavyweight.The reality is that your use case is a tiny subset of the total number of rails users. Most of us are trying to solve a specific problem, rather than trying to glue together ''mini apps''. Rails is a web development framework, not a chunk of glue for plugins.> Please, set the issues of backwards compatibility aside or personal > preference and argue with merit alone.We have hundreds of thousands of downloads now. Setting aside backwards compatibility isn''t an option. As for merit, your proposal only makes sense if we believe that reusable mini apps will ever be a viable technique for the majority of developers. That''s debatable at best. I can''t see what is to stop you from releasing a plugin which uses our current configuration options for controller model and view paths to supports this functionality. Before we''d seriously consider including this kind of functionality it would have to be *seriously* battle tested, and considered an improvement by everyone that tried 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 Jun 16, 5:33 pm, "Michael Koziarski" <mich...@koziarski.com> wrote:> I can''t see what is to stop you from releasing a plugin which uses our > current configuration options for controller model and view paths to > supports this functionality. Before we''d seriously consider > including this kind of functionality it would have to be *seriously* > battle tested, and considered an improvement by everyone that tried > it.I definitely agree that a plugin would be the best way to test the functionality before it could be seriously considered for core. I''m just trying to gauge the value of the idea and the openness of the core team before I attempt something that strenuous. -- John Long http://wiseheartdesign.com http://radiantcms.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 -~----------~----~----~----~------~----~------~--~---
Although I don''t see the practicality of grouping everything like you
intend, I could see grouping the controller helpers and views
together, but leaving the models separate:
app/
application/
application_controller.rb
application_helper.rb
views/
layout.rhtml
accounts/
accounts_controller.rb
accounts_helper.rb
views/
layout.rhtml
edit.rhtml
login.rhtml
signup.rhtml
models/
account.rb
Typically the helper and views are related to the controller itself,
so this seems resonable.
nkryptic
On Jun 16, 11:51 am, "John W. Long" <johnwlong2...@gmail.com>
wrote:> On Jun 15, 10:45 pm, "Michael Koziarski"
<mich...@koziarski.com>
> wrote:
>
> > Is this even true? We have configurable load paths, controller
> > paths, and view paths. I simply can''t see how the directory
structure
> > is even on the list of the top ten problems to
''modularization'' of a
> > rails application.
>
> My experience with building an extension system for Radiant tells me
> that it is. Radiant extensions provide an app directory with places
> for controllers, views, and models--just like Rails--and the whole
> thing seems extremely heavyweight.
>
> Granted I can easily fix the layout for the Radiant extension system,
> but that would kind of defeat the purpose. Radiant extensions are
> supposed to look like mini-rails apps.
>
> I believe the whole thing reveals a systemic problem with the way the
> Rails directory structure was designed. A bold claim, I know, but I
> believe it''s true.
>
> Again, what exactly is the point of organizing files by type? Our
> applications have logical structure, why not reflect that in directory
> layout?
>
> Perhaps the example laid out in my article is a bit extreme. I''d
see
> it as a win if we just moved to a directory per related controller,
> model, and views:
>
> app/
> application/
> application_controller.rb
> application_layout.rhtml
> accounts/
> account.rb
> accounts_controller.rb
> accounts_helper.rb
> accounts_edit.rhtml
> accounts_login.rhtml
> accounts_signup.rhtml
> posts/
> post.rb
> posts_controller.rb
> posts_helper.rb
> posts_index.rhtml
> posts_archive.rhtml
> posts_post.rhtml
> comments/
> comment.rb
> comments_controller.rb
> comments_helper.rb
> comments_list.rhtml
>
> Is that not 10 times cleaner and easier to navigate? Now I can `mate
> app/comments` to work on a single controller and related views.
>
> Please, set the issues of backwards compatibility aside or personal
> preference and argue with merit alone.
>
> --
> John Longhttp://wiseheartdesign.comhttp://radiantcms.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 Sat, Jun 16, 2007 at 03:51:05PM -0000, John W. Long wrote:> Again, what exactly is the point of organizing files by type? OurSo you know, absolutely, where a particular file will be. "I''m looking for the Foo model, so that''ll be in app/modules/foo.rb". It becomes a little fuzzier as to where your files are when your models might be tied to one of a number of different "chunks" of the app.> applications have logical structure, why not reflect that in directory > layout?In that case, I''d say that you would want to allow a free-form directory structure under app/, which is not very opinionated, will cause endless holy wars, and doesn''t fit with the rest of the Rails Way (as I see it).> Perhaps the example laid out in my article is a bit extreme. I''d see > it as a win if we just moved to a directory per related controller, > model, and views:Remove ''model'' from that list, and you''d be awfully close to having my vote. The views, helpers, and controller do all tend to relate quite closely together. Models, though, often permeate between various controllers.> Please, set the issues of backwards compatibility aside or personal > preference and argue with merit alone.How much of this discussion *doesn''t* ultimately come down to personal preference? Do you have any hard, objective facts in favour of your proposed layout? I don''t know of anything that objectively supports Rails'' current way of doing things. - Matt --~--~---------~--~----~------------~-------~--~----~ 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 think this discussion is slightly off-center. It seems that most people are criticizing John Long''s solution rather than discussing the problem he''s trying to solve. The advantage to breaking out an application by function rather than type is that you can then package up an entire area of one project and use it in another. Just to clarify, I''m not saying that all applications should be built with this in mind and that all applications can be separated out by functional area, but rather that if there were functional areas of a site you''d like to reuse in another rails application, it becomes difficult. Plugins are the beginning of code sharing, but they simply aren''t powerful enough (no direct support for views, routing, database migrations, public assets, etc). This is a problem that many people have tried solving in one way or another (Plugin-a-week''s appable_plugins, Rails Engines, RHG''s Plugems, Radiant''s extension system, etc) but really should be discussed and solved at the core level. -Warren On Jun 15, 5:55 pm, "John W. Long" <johnwlong2...@gmail.com> wrote:> I''ve written an article suggesting some radical changes to the Rails > directory structure for Rails 2.0 and am curious to know the core > team''s thoughts about it: > > http://wiseheartdesign.com/2007/6/15/better-modularization-for-rails-... > > -- > John Longhttp://wiseheartdesign.comhttp://radiantcms.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 -~----------~----~----~----~------~----~------~--~---
First of all, I totally agree with this message. But I think you should be careful about saying the problem should be solved in the Rails core. The core team''s distaste for high-level components, is well-known and well-justified. The crux of the matter is that the mechanics of modular code don''t have a standard best-practice solution. Every component system has it''s own requirements. There can be no one-size-fits-all solution. And if you look at Rails, it''s pretty good at sticking to best practices and solutions that work in the vast majority of cases. So rather than say that Rails core should solve this problem. I would say Rails core should SUPPORT THE SOLVING OF this problem. Modular development is going to happen on top of Rails simply because it''s such an awesome infrastructure. I believe the core team can support that kind of development with a few patches here and there without comprimising the original focus or cleanliness of the Rails codebase. Just to give an example, if John develops this plugin as-is, there could be a performance problem with adding too many things to the load path. A good patch to solve that would give Rails a more efficient way to look for these files according to a new naming convention. Such a patch would be minimally disruptive to Rails, but could open up whole new avenues for development on top of Rails. On 6/17/07, wkonkel@gmail.com <wkonkel@gmail.com> wrote:> Plugins are the beginning of code sharing, but they simply aren''t > powerful enough (no direct support for views, routing, database > migrations, public assets, etc). This is a problem that many people > have tried solving in one way or another (Plugin-a-week''s > appable_plugins, Rails Engines, RHG''s Plugems, Radiant''s extension > system, etc) but really should be discussed and solved at the core > level.--~--~---------~--~----~------------~-------~--~----~ 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 6/17/07, Gabe da Silveira <gabriel.d@gmail.com> wrote:> > > So rather than say that Rails core should solve this problem. I would > say Rails core should SUPPORT THE SOLVING OF this problem.Just like localization. +1 for solving outside of Rails core. --~--~---------~--~----~------------~-------~--~----~ 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 6/18/07, Mislav Marohnić <mislav.marohnic@gmail.com> wrote:> On 6/17/07, Gabe da Silveira <gabriel.d@gmail.com> wrote: > > > > So rather than say that Rails core should solve this problem. I would > > say Rails core should SUPPORT THE SOLVING OF this problem. > > Just like localization. > +1 for solving outside of Rails core.The high level components that we have were removed for a reason. If the plugin community can come up with something kickass we can revisit the issue. For now, reuse of app slices is a pipe dream in any language, and it's a problem we're not looking to solve in rails itself, at least for the foreseeable future. -- 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 6/17/07, Michael Koziarski <michael@koziarski.com> wrote:> On 6/18/07, Mislav Marohnić <mislav.marohnic@gmail.com> wrote: > > On 6/17/07, Gabe da Silveira <gabriel.d@gmail.com> wrote: > > > > > > So rather than say that Rails core should solve this problem. I would > > > say Rails core should SUPPORT THE SOLVING OF this problem. > > > > Just like localization. > > +1 for solving outside of Rails core. > > The high level components that we have were removed for a reason. If > the plugin community can come up with something kickass we can revisit > the issue. For now, reuse of app slices is a pipe dream in any > language, and it's a problem we're not looking to solve in rails > itself, at least for the foreseeable future. >Given this reply, I'm not really sure what your position is at the moment. Given that we *all* agree that some forms of "code sharing" are best enabled outside of core, do you believe that there is value for some people in having this ability, and that it's worth considering the design of the framework such that it *can* be used in these cases, where it doesn't negatively impact "normal" use? -- * J * ~ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
> Given this reply, I''m not really sure what your position is at the > moment. Given that we *all* agree that some forms of "code sharing" > are best enabled outside of core, do you believe that there is value > for some people in having this ability, and that it''s worth > considering the design of the framework such that it *can* be used in > these cases, where it doesn''t negatively impact "normal" use?If plugin authors are having a hard time accomplishing their goals, and a small non-intrusive patch will make their lives easier, it''s probably a win for everyone involved. -- 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 -~----------~----~----~----~------~----~------~--~---
I like the idea overall but I don''t like throwing my views in with my code. Perhaps keeping the views in another subfolder (within a particular ''slice'') would maintain the notion of separation of concerns a little better. Otherwise I''m a fan of the idea. -James --~--~---------~--~----~------------~-------~--~----~ 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 agree with David. I think that the Rails development team should now develop more high-level reuse of the sub-set than changing all the base Rails was created. I am not saying that the "Django-style" is bad, I really like it. But Rails-style is nice and cool to, so why change something that work for another thing that work too, but in another way? Júlio Santos Monteiro - http://monteiro.eti.br On 15 jun, 19:29, DHH <david.heineme...@gmail.com> wrote:> > I''ve written an article suggesting some radical changes to the Rails > > directory structure for Rails 2.0 and am curious to know the core > > team''s thoughts about it: > > Thanks for thinking about this John, but I don''t see Rails adopting > something along those lines right now. We can definitely do more to > improve high-level reuse for the sub-set of users who need it, but it > probably won''t be setting the tone quite as dramatically as this. I > much prefer to have things divided by type when I''m just working on a > single application. And anything that includes prefixing underscores > is a visual non-starter for me ;).--~--~---------~--~----~------------~-------~--~----~ 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 Jun 17, 3:00 am, Matthew Palmer <mpal...@hezmatt.org> wrote:> Remove ''model'' from that list, and you''d be awfully close to having my vote. > The views, helpers, and controller do all tend to relate quite closely > together. Models, though, often permeate between various controllers. >+1 that putting Models along with VC is a baaaaaaaaad idea. Simple apps often have a 1:1 M:C - but once the app grows, very often Models are used throughout, not directly corresponding to 1 and only 1 controller. Controllers define a UI, Models define a domain - the two are not necessarily mappings of eachother. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---