[eluser]plainas[/eluser]
Ok, my application is starting to get complete and here and there I stepped on some dilemmas that I wouldn't like to face next time.
I read somewhere on some article about rails (if I remember correctly) that going for a megalithic (monolithic) controller was a bad strategy and should be avoided.
I was stupid enough to follow this advice and I forced the splitting of what should naturally be a controller into two controllers just because it was reaching 600 lines of code.
That was a mistake because I latter found myself creating workarounds to fetch stuff that could be reached simply by reference to the controller class in case I would use only one controller.
Now, the question is not, when to use more than one controller, its more like: what should a controller contain and what motivates the creation of another controller?
I would like to ear different opinions on this.
Personally I won't repeat my mistake. Unless I have a set of features on my application that will use a totally distinct part of my database, I will wrap everything on the same controller.
Other kind of dilemma I had was where to draw the model-controller and controller-view boundaries.
Like, the vies support loops, but what should the loop contain. For example, lets say I want to output an HTML table. I can prepare each row on the controller and then simply loop trhough them on the view. Or I can put the elements into an array and then add the HTML tr and td tags as i loop in the view. Or I can prepare the whole table in the controller and then just place it in the right spot in the view.
The same aplies to the model, how raw should the data be in the controller? Using the controller just as a database end point makes it kind of useless. On the other hand, too much data prepp, sanitation, etc. in the model will bring to much application logic into it making the controller a bit confusing.
I guess these are mostly a matter of personal preference. Anyway, any tips for good application design usgin CI?
