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.
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.
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.
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?
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.
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.
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?
+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.