"Modular" application design - controller / route setup

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

On Mon, May 30, 2011 at 3:26 PM, Mickiii [email protected]
wrote:

/Sales/Invoices <- sales invoice index
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.

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

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs