halfbit
halfbit

Reputation: 3939

Rails's way of 'convention over configuration'; are there pitfalls?

After many years of C/C++, PHP, some Ruby and other languages on one hand an different projects with different frameworks on the other, I now want to learn Rails.

After working through (Getting started-) Guides, I think Rails is powerfull and fairly easy to learn. And I feel ready to start with a non Bookshop app.

But a friend warned me about Rails's 'convention over configuration' and the way it 'does things'. I cant see a 'problem' with that, but are there pitfalls?

And: Are there things Rails does very different than other framworks?

Upvotes: 0

Views: 376

Answers (4)

Rupali
Rupali

Reputation: 321

When writing application using any framework it may be necessary to write a lot of configuration code. However if we follow Rails Standard conventions then it is possible to avoid the excess configuration and in some cases no configuration at all. Thus, explicit configuration would be needed only in those cases where you can't follow the standard convention. Following are the conventions provided by rails:

Naming conventions: Active Record uses some naming conventions to find out how the mapping between models and database tables should be created. Rails will pluralize your class names to find the respective database table. So, for a class Book, you should have a database table called books. Example: Database Table - Plural with underscores separating words (e.g., book_clubs). Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

Schema Conventions: Active Record uses naming conventions for the columns in database tables, depending on the purpose of these columns. Foreign keys - These fields should be named following the pattern singularized_table_name_id (e.g., item_id, order_id). These are the fields that Active Record will look for when you create associations between your models. Primary keys - By default, Active Record will use an integer column named id as the table's primary key. When using migrations to create your tables, this column will be automatically created.

Upvotes: 1

halfbit
halfbit

Reputation: 3939

There is a point I never had before, that took me a nerve or two: Rails is caching a lot - even in development env. (for gods sake it does!)

Let me construct a scenario (no; not a construct, happend to me in a more complex variant)

After enough hours of work and you did all that was on the plan for the day, you close with a little cleanup. Check evering is still working - smile - and off

sleep

Back to the Computer you start all up and get a 'constant xy is not ...', so but, but why, overnight?

The answer is easy (if someone tells you at least once): Rail's caching does not (or better cant) check if a class / file / method is just removed, and not altered (sometimes ...)

So the (one to many) deleted file removed the Class, it contained from the world, but not from Rail's cache. Power off did the rest.

I had more subtile situations, that i solved with a rails server restart after i looked out of the window, if I am still on earth ...

What I try to point out is, there is no magic behind, but be warned, if you think you are smart enough to touch the framework code (why and how ever you want to do that). Big cache gets you back where you are, at beginners level.

Upvotes: 0

halfbit
halfbit

Reputation: 3939

What your friend says is only somehow true. Rails's naming conventions are powerfull and keep your brain free for other things.

But: If you think you have experience ... you are learning Rails -> you are back to school.

Rail's 'naming conventions' are not only conventions. They are Rails somehow. So if you break the convention, you are off road and soon in the middle of no where. I think that this part of Rails could be better pointed out in Guides.

Let me give an example: (you are tired of "books" and start wit a little app around 'Pubs')

You scaffold your Pup (intended typo)

You then put in some logic, put some work, then you realize your (oops) typo. Now dark clouds arise. Since you are experienced, you start correcting the typo ... PupsController -> PubsController, filename of PubsController (you are already off road) ...

You will end up at the database table 'pups' ... (middle of nowhere)

This happened because you think you are experienced. A beginner has built a new scaffold (without typo) or asked here on SO how to correct 'correctly')

An other example is to name thigs 'more nice'. After years and many projects you are probably one, that never uses "unspecified" names like 'user','role','guest','owner' for classes and so on. So you start to name them (nicley?): PubUser, PubOwner, ... Noboddy told you "DON'T".

You put all in a namespace (there are many people here saying "don't") with the nice name 'PubApp'

Although your files are well organized, you will end in tablenames: pub_app_pub_owners and so on, not to think about the name of assotiative Tables between them.

And later on you will type something like

link_to 'add' new_pub_app_pub_pub_guest_url   
link_to 'add' new_pub_app_pub_owner_pub_url   

This is probaly not what your intention was to make things 'clean'. And if you take a look at the 'beginers' link...

link_to 'add' new_pub_guest_url

What I do not want is to preferre one or the other.

I want to point out, that - since you are not experienced with Rails - you dont know where the things you are doing (off road) are leading you. With only a hard way to return.

Thats somehow a pitfall.

But next time you will know about that and make a compromise: 'Pubowner' and 'Guest' (and 'pa' as namespace (if you realy want to)

so

link_to 'add' new_pa_pubowner_guest_url 

Is not so bad. But its hard to reverse things so think before ...

Upvotes: 1

Philip Hallstrom
Philip Hallstrom

Reputation: 19879

You're going to either get zero replies or a bunch of opinions. I would recommend googling for "rails is opinionated". Hopefully that will turn up more examples of what you might run into.

Is it a problem? No, not really. Can it be a problem? Yes, absolutely.

Integrating with legacy databases can be a PITA sometimes. Or if you have some insane desire to name all your primary keys something other than "id" that can be a problem.

Not so much a problem really, but you're fighting a lot of convention.

Really, other than legacy databases I can't think of anything off the top of my head bothers me about it's conventions.

Upvotes: 1

Related Questions