Welcome Guest, Not a member yet? Register   Sign In
General question: Seperate controller or a function???

I am looking for some advice.

user> user_profile> education
user> user_profile> work

should i make
class user_profile extends controller {
function education($action) {
case "add":


case "update":



function work($action) {
case "add":


case "update":



or make a controller for education and work??

It's all up to you. I used to create big controllers with all functionality related to a certain topic in one controller. But in the end that makes it harder and harder to find problems when they arise.
I've slowly started to divide functions over more controllers for maintainability, even in some "finished" applications (as far as such a thing as a "finished" internet application exists). And functions that need to be shared between functions from different controllers go into libraries. It makes for very readable controllers that are easily read and maintained, or functionally changed because of those first two. (especially when you really put all your HTML in views and language in language files)

There also might be a memory arguement to be made, but I've never done any testing on whether functionally equal implementations with one or multiple controllers have significantly different memory or processing time requirements.

Also I'd suggest using different functions for add & update instead of switches for add and update cases, but that's also more an opinion for readability than really based on any functional arguement.

I tend to break controllers down into logical structures that are easy to deal with. Controllers that hold a whole lot of functions like that can turn into a hairy mess really quick.

You can put the work and education into their own controller and still have the url structure you are going for because controller + function does not = url. Look into the routing functions, I think they are fairly simple. For example, you could do something like (and this is without testing)

$route["user_profile/(:any)/work"] = "work/index/$1";

What this would (hopefully) do is send a url http://www.domain.com/user_profile/jimmy05/work to the controller Work, the function index, and the parameter 'jimmy05' (a username).

Hope that helps.

tx guys for your answer. Still learning to structure my code and logic a bit more MVC.

I going for the controller option, creating a controller to make it more manageable.

Another question within a controller, like making a table. Do you parse the table in the controller and sent it to a view file or do you sent an array to a view file and make a foreach function in the view file???

Best practice is the latter.

If you wonder if an action belongs in a view or not, the rule of thumb is: is it about presentation or are you manipulating your data?
When you're manipulating the data it should go into the controller. When it's about presentation it should go into the view.

Putting it into a table is a presentational decision, in addition to which you which might need CSS classes or ID's, and those are presentational concerns. So it should be generated in the view.
Another rule of thumb: there should never be any HTML in your controllers. Though I must admit I've taken some "short-cuts" in the past, I've almost always removed the HTML at a later time. That's also in part about maintaining and reading your own code: excising the HTML from your controllers makes you code a lot shorter and a lot easier to read.

Depends on situation but 99% of the time you should put html to the view files and loop the results there with for example foreach. If you use the table helper, thats a little bit of grey area. I dont use it at all anymore and have got the impression that a lot of other CI'ers dont use it anymore as it slightly is against the MVC pattern. But one can say that even using form or other helpers are against it so go figure Wink

Theme © iAndrew 2016 - Forum software by © MyBB