I'm at a standstill....need help with controllers (theory)

[eluser]Colin Williams[/eluser]

Because obviously I have no plan table in my database, there are many tables in my database that eventually becomes the plan. Is this when the idea of a “plan” object focused controller breaks down a bit and I need to look at smaller controllers?

So, a plan is still an object, it's just represented by several tables. An object need not map to a single table. Models need not even map to a single table.

Do you need to break that down into smaller controllers? I don't necessarily think so, unless there are enough independent actions to take on each piece of a plan, or there will be in a later phase. MVC is an organizational pattern, so designing your app can be a bit like information architecture. Ask yourself, "6 months from now, when I need to update the 'plan' system, where is the most logical place I or another programmer would look?"

This is partly why documenting as you build is a good idea because every time you find yourself adding another caveat to an explaination, you discover areas that could be organized more intuitively.

[eluser]Colin Williams[/eluser]
I actually have a similar real-world scenario happening now. I'm adding a feature to site through which users can create and manage "bike checks" and share these with other users, embed them in social networking sites, etc.

The main object is a bike. A bike is made up of bike parts and some meta info. Bike parts are made up of bike manufacturers and bike part types. I've got a lot of different objects coming together to make one bike object.

I've settled on breaking it down into several controllers, all nested under bike:

bike
bike/add
bike/edit
bike/delete
bike/view

bike/part/view
bike/part/add
bike/part/edit
bike/part/delete

bike/manufacturer/add
...

bike/part_type/add
...

[eluser]jleequeen[/eluser]
[quote author="Colin Williams" date="1220137703"]I actually have a similar real-world scenario happening now. I'm adding a feature to site through which users can create and manage "bike checks" and share these with other users, embed them in social networking sites, etc.

The main object is a bike. A bike is made up of bike parts and some meta info. Bike parts are made up of bike manufacturers and bike part types. I've got a lot of different objects coming together to make one bike object.

I've settled on breaking it down into several controllers, all nested under bike:

bike
bike/add
bike/edit
bike/delete
bike/view

bike/part/view
bike/part/add
bike/part/edit
bike/part/delete

bike/manufacturer/add
...

bike/part_type/add
...[/quote]

Does that mean your using controller subfolders? you have a bike controller, but then you have a bike subfolder with a part controller..and manufacturer controller??

[eluser]Colin Williams[/eluser]
Correct.

app/controllers/bike.php
app/controllers/bike/part.php
app/controllers/bike/manufacturer.php

More and more I don't like how bike.php falls out of the other group, so I've considered moving it to app/controllers/bike/core.php, but I equally don't like setting up routing when it isn't absolutely necessary.. IDK, still up in the air about it.

I might also mention that I have one Bike_model, prototyped like:

Code:

Bike_model
    save_bike()
    get_bike()
    save_part()
    get_part()
    save_manufacturer()
    get_manufacturer()
    [...]

To me, it's nice having that as one unit.

[eluser]jleequeen[/eluser]
Gotcha! I think that is what will help me find that happy medium between keeping things grouped together, but being able to keep my controllers small and discrete. Thanks a lot for your input Colin. It has been very helpful.

[eluser]ontguy[/eluser]
@Colin Williams - I am curious about how you group the views for your controllers?

app/views/bike/add.php
app/views/bike/view.php
..
app/views/bike/part/add.php
app/views/bike/part/view.php
..
app/views/bike/manufacturer/add.php
app/views/bike/manufacturer/view.php
etc..

[eluser]stuffradio[/eluser]
ontguy, I don't know what Colin does... but that is basically a good way to group it.

In your controller it could be something like

Code:

<?php

class Bike extends Controller {

  function Bike()
  {
    parent::Controller();
    $this->load->helper('url');
  }

  function add()
  {
    $this->load->view('bike/add');
  }

}

That's a basic example of how I would do it.

[eluser]Colin Williams[/eluser]
I just have a single sub-folder in views like:

app/views/bike/bike_form.php
app/views/bike/part_form.php
app/views/bike/manufacturer_form.php
app/views/bike/bike.php
app/views/bike/part.php
...

And those are just fragments of the final pages that are rendered.

[eluser]ontguy[/eluser]
I gave this structure a try:

app/controllers/bike.php
app/controllers/bike/part.php

When I go to URL/bike/part
it gives me a "404 Page Not Found"

When I removed the file bike.php, it works.

Did any changes need to made to CI through extensions or otherwise for this to work?

[eluser]Colin Williams[/eluser]
Huh.. you're right, ontguy. Guess we'll need to use routes for this or rethink the structure. That's frustrating, but it makes sense. Otherwise, CI would find bike.php and think "okay, lemme instantiate this Bike class," then when it inevitably doesn't find the "part" function, it would have to start over and look for a 'bike/part.php' file, and continue on. Guess that's not such a stretch, but it's obvious to see that this is not what's happening.