How to structure related controllers?

[eluser]kyleect[/eluser]
I had a question about how to structure related controllers. I'm currently working on a simple transaction application to keep track of transactions in a checking/savings account. Here is my basic database

users
-id
-name

accounts
-id
-user_id
-account_number

transactions
-id
-account_number
-amount
-date

As you can see. Users have ownership over accounts and accounts have ownership over transactions. Where I'm running in to an issue is how to structure my controllers and models. For example, if I wanted to view a single transaction, I would like have the following uri path: "transactions/view/$transaction_id". Now I want to view all the transactions for an account. The first uri path that came to mind is "accounts/transactions/$account_number". Is this considered bad practice? I'm creating transaction behavior inside the Account controller. Would it be better to have "transactions/list/$account_number"? I understand that both of these will work however I'm trying to figure out what makes the most sense from programming and symantics point of view.

[eluser]Jelmer[/eluser]
What makes the most sense is mostly up to you and what your application demands. If you're gonna have more operations with transactions then just list (like add/edit), I'd recommend putting it all in a seperate controller (which would mean /transactions/list/$account_id). If the only thing will be the list, it would probably make more sense to handle it like a property of the accounts and put it in the accounts controller.

It's partly about semantics and partly about the demands of your application. It's often a bad practice to build huge controllers and a lot better to split them up by their goals. But on the other hand, I wouldn't create a controller just for 1 function - in that case it'd be better to treat it as a property of another class.