Better Modularization for Rails 2.0
John W. Long
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/
Mislav Marohnić
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:
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.
DHH
> 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 ;).
Rick Olson
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
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.
--
Gabe da Silveira
http://darwinweb.net
Ben Munat
"_foo" == :-(
b
John W. Long
> 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.
Matthew Palmer
>
> 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
Michael Koziarski
> 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
Tyler McMullen
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
Gabe da Silveira
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?
Neil Wilson
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
John W. Long
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.
Obie Fernandez
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
Frederick Cheung
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
John W. Long
wrote:
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.
dasil003
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.
Michael Koziarski
> 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
John W. Long
> 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.
nkry...@gmail.com
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
Matthew Palmer
> Again, what exactly is the point of organizing files by type? Our
So 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
wko...@gmail.com
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-...
Gabe da Silveira
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.
Mislav Marohnić
So rather than say that Rails core should solve this problem. I would
say Rails core should SUPPORT THE SOLVING OF this problem.
+1 for solving outside of Rails core.
Michael Koziarski
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
James Adam
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 *
~
Michael Koziarski
> 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
james.thompson
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
Julio Santos Monteiro
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
S. Robert James
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.