Is Rails DRY?

rubyonrails-talk
1

I note that every time a new rails app is made, there is a huge bunch of directories and files generated. As this is the same thing every time, is it really DRY? It just seems that there would be a way to have a standard set of directories and the classes could be extended when required.

Am I just being naive?

2

There are not that many files. Most of them are for configuration and a few defaults like application_helper.rb or application.rb They're necessary anyway. Then there are lots of directories. Most of them empty to start with, but nearly all of them necessary, too.

Sorry, but I can't see your point. Maybe give us some example, which directories or files you think are unneeded?

3

Lloyd Linklater wrote:

I note that every time a new rails app is made, there is a huge bunch of directories and files generated. As this is the same thing every time, is it really DRY? It just seems that there would be a way to have a standard set of directories and the classes could be extended when required.

DRY refers to code that you - the end-developer - must maintain.

For example, if you generate two projects, most of the boilerplate code is indeed duplicated, but you don't need to maintain it.

You will indeed need to deploy it! That's where it goes to work.

But if, for example, your two projects share a common Member model - you should use some extra-Rails facility to merge them together, such as a library folder at RAILS_ROOT + '/../lib'.

(Remember to pass all tests in both projects each time you integrate!)

So DRY at the level of Rails source is really "meta-DRY". Its excesses allow your own code to remain DRY.

4

Phlip wrote:

But if, for example, your two projects share a common Member model - you should use some extra-Rails facility to merge them together, such as a library folder at RAILS_ROOT + '/../lib'.

(Remember to pass all tests in both projects each time you integrate!)

So DRY at the level of Rails source is really "meta-DRY". Its excesses allow your own code to remain DRY.

Thanks, Phlip! I will look into how to join common members.

5

Lloyd Linklater wrote:

But if, for example, your two projects share a common Member model - you should use some extra-Rails facility to merge them together, such as a library folder at RAILS_ROOT + '/../lib'.

Thanks, Phlip! I will look into how to join common members.

Ask a new question here on how to. I'm sure my first few attempts would be "wrong". Not irreversibly wrong, but sub-level compared to the state of the art here.