"Modular" application design - controller / route setup

rubyonrails-talk
1

I am fairly new to rails, and have been through a few books, and am now starting to sketch out an application, however I have run into a problem with regards to the structure of the app.

I want to build an application that is setup in modules, and examples of urls could be:

/Sales <- frontpage for sales /Sales/Customers <- customer index /Sales/Customer/123 <- Customer 123 /Sales/Invoices <- sales invoice index /Sales/Invoice/123 <- show invoice 123 /Sales/Invoice/123/Post <- post action for the invoice /Purchase <- frontpage for purchases /Purchase/Vendors <- vendor index /Settings/Currencies <- currency index etc...

So in short, I would like to build the app with modules of sales, purchase, inventory etc. What is the best way of setting this up? Do I make a controller for each module, i.e. sales_controller, purchase_controller or should I use namespaces and routes for this or is there a better way?

Any help and best practices on this is very much appreciated.

Thanks in advance

2

I am fairly new to rails, and have been through a few books, and am

now starting to sketch out an application, however I have run into a

problem with regards to the structure of the app.

I want to build an application that is setup in modules, and examples

of urls could be:

/Sales ← frontpage for sales

/Sales/Customers ← customer index

/Sales/Customer/123 ← Customer 123

/Sales/Invoices ← sales invoice index

/Sales/Invoice/123 ← show invoice 123

/Sales/Invoice/123/Post ← post action for the invoice

/Purchase ← frontpage for purchases

/Purchase/Vendors ← vendor index

/Settings/Currencies ← currency index

etc…

So in short, I would like to build the app with modules of sales,

purchase, inventory etc. What is the best way of setting this up? Do I

make a controller for each module, i.e. sales_controller,

purchase_controller or should I use namespaces and routes for this or

is there a better way?

Any help and best practices on this is very much appreciated.

I have seen a few questions similar recently, here’s an opinion, and what is my ‘best practice’ when faced with design questions. I would recommend that rather than try to figure out the right structure beforehand, that you build your app incrementally (and in a test driven manner for sure) and contend that through that process you will derive the right structure.

I.e. you know you need to have users so build up a user model and controller and implement authentication. Then go to what the user would do next in the app. Yes, you will change and have to redo things as you go but in reality I would put money that you end up with a prettier design that grew organically. This does mean that you have discipline and when you see an issue — whether in structure or even just how you have named something that you dont overlook it and make necessary changes as you go.

Just a thought… this aproach has worked well for me, much better than planning ahead, believe it or not.

3

I tend to agree with David here. Doing this in a test-driven way will reveal some best practices.

That being said, I think you’re likely better off not fighting with Rails defaults. So, instead of “/Sales”, just use “/sales”. Other routes would be:

/sales

/sales/customers

/sales/customers/123

/sales/invoices

/sales/invoices/123

/sales/invoices/123/Post … no such thing. it would just be:

POST /sales/invoices/123 … if for some reason you need to POST to invoice 123 (sure it’s not a PUT instead?).

/purchases

/purchases/vendors

etc.

Opinions differ on whether it’s better REST practice to have a URL like /sales/customer/123 or /sales/customers/123, but both make sense, and Rails chooses the latter, so it’s easier to just go with the Rails default. Someone once pointed out to me that Yahoo and Google use the singular form, but all you have to do is go to http://sports.yahoo.com/nba/players and http://sports.yahoo.com/nba/players/3252 to see counter-examples.

Bryan

4

Thanks for your comments, good advice. Test-driven development is the best way to develop and grow the applications. I am coming from CakePHP, but Rails is beginning to grow on me.

Anyway, related to my original question, this solved the issue for me:

resource :sales, :only => [:show] do   resources :customers end

Now time will tell whether this is a viable solution of not.

Michael