[eluser]jleequeen[/eluser]
I've been working on recoding an app of mine in CI and I'm getting to the point where I'm not so sure my initial thinking of how to lay out my app was the best way. Before I began recoding my app, I sat down and roughly sketched out what made logical sense. I looked at a controller as almost the main sections of my apps (or main tabs if you want to think of it that way) then I fell into the trap of letting my menus affect how I was laying out my app. For instance, if I had a "Users" tab and it had submenu items, they became my methods which works ok for that particular thing, but not for others. For instance, I had a bunch of data entry forms, that together make up a plan a user would submit when finished. Well, in my sketch I thought it would be a good idea to create a "plan" controller and place each form as a method. Well obviously it didn't take long before that "plan" controller had a lot of methods in it and while putting a lot of things in the constructor that say more than half of the forms would use was convenient, it surely didn't make much sense to have that overhead on forms that didn't need it. Not to mention the controller code getting unmanageable (especially when you add in validation for each form).
I've come to the conclusion that, while it seems nice and tidy from a "grouping standpoint" to create a single controller that does a lot of stuff...with a lot of methods and views, it's kinda defeating the purpose of why I wanted to use a framework to clean up and structure my code better. I use to design my apps on a page/view basis..and throw the controller code up at the top of each view file, like I'm sure most beginners with php use to. But, I saw the need for structure and consistency and separation and that lead me to CI. Now, although I'm excited about what CI allows me to do along with all the handy pieces that make life easier, I'm stuck in this quandary with controllers and app layout.
I loved the view-centric design approach because it was easy and made you design from what the user interface first. I think I would be better off incorporating that approach into CI without the spaghetti code. Use CI for the separation but still design view-centric. But this would cause me to totally rethink the way I was thinking about controllers. Basically I would be looking at one controller per view. Maybe that's not such a bad thing after all. I was reminded the other day in an old article when Rasmus Lerdorf said "Keep controllers small and very close to the view". I feel like I am easily losing sight of that by having controllers that are trying to do too much.
Did anyone else have this trouble when they began using CI from a spaghetti code background. Did you began to confuse your app layout so it made sense URL wise? Doesn't it make some sense to keep things compact and neat and controllers being very specific? I realize basically what it's boiling down to, at least for me is almost what Rasmus recommended in his "No-framework Framework" post that I'm sure everyone has read. Instead though of just using separate include files to split up my code, I'd rather use CI.
I'd love to hear everyone's two cents.
