CONTROLLERS, single method or different methods for different actions?

As for the colour removal, I would do the customer form as a normal form, but deleting and adding colours as a javascript function, so when the user deletes a colour it just pops off the screen (with a 'saving changes' pause in the middle - I always love using those animated loading gifs), without the user having to refresh the page for such a minor thing.

Alternatively, make the 'Edit Colours' a seperate form altogether. It is just a matter of user interface design. For the user sometimes doing this in a blocky way can be easier to follow. "How do I change my favourite colours?" "Ah, here is a big button that takes me to a nice clean screen that enable me to do that".

For me, for speed of coding I would do the blocky multi page approach, for quality experience I would do the javascript approach. Personally I try to avoid using 'flags' in hidden form fields as much as possible.

Thanks, I have gone with the "quality" experience where colours can be assigned to a customer (or removed from a customer) using JavaScript / Ajax (colours are a many to one relationship). It works fine and is less clicks and less screens for the user to contend with, but what I am still unsure about is whether to route this to a different method to the one used to change the normal customer details (such as name and email address), or to a master method which then figures out whether the user is trying to change the customers email address, or whether they're trying to add or remove colours.

But if I had separate forms all going to the same controller, using a hidden task field, had I might as well not just have separate forms routing to separate controller methods?

for me - the advantage is that i only have one public method in the controller and the only thing that method is doing is routing to the different private methods depending on which form it is. this keeps the forms simpler - they all go to the same place. and it keeps the controller safer because none of the form methods are public. and a small benefit is being able to look at the public method in the controller and very quickly see what forms are calling on it and which methods they route to.

OK point taken, this makes sense. I did it this way initially and ended up with a big fat controller. Then I modified it slightly so it was a main controller, and I created several private sub controllers.

Then I changed it again into separate public controllers, and pointed the different forms on the page to the relevant controllers (basically the opposite to what you're saying above). Now I'm inclined to go with what you're saying and change it back again!

At some stage I'm going to have to get on with actually building the system, but I am going round in circles at the moment trying to get a feel for what is most appropriate way of doing things.

i think its good to keep trying different things. one suggestion is to push as much as possible to your models. basically the controller just asks if the form validated or did a result come back from the database search - and then chooses the appropriate view based on what happened. that keeps your controller as 'thin' as possible, and the ever changing granular details like field names are in the models.

But we're in the PHP7 era now and "private" has a specific meaning. Also, making controller methods really private by using the keyword works just fine - you don't need to prefix those with an underscore and they still won't be routable.

(hangs head in shame) ok not really, but - yeah i thought the underscore prefix for the method name was still a 'convention' for helping to identify private methods in php - and it was including zend in early 2015 - but apparently in late 2015 it was removed in zend and the consensus is now not to use it.

It may still be present in some conventions, CI too denotes non-public methods that way for easier readability.

What I was explaining is that you don't actually need to use it and that he term "private" means a different thing.

It may still be present in some conventions, CI too denotes non-public methods that way for easier readability.

What I was explaining is that you don't actually need to use it and that he term "private" means a different thing.

well then what does 'private' mean? i am referring specifically to what is in the codeigniter 3 manual for how to prevent methods in a controller from being publicly available. is there something else that bears on this and if yes please explain or link to a source so we can understand what you are referring to.
https://codeigniter.com/user_guide/gener...te-methods

It may still be present in some conventions, CI too denotes non-public methods that way for easier readability.

What I was explaining is that you don't actually need to use it and that he term "private" means a different thing.

well then what does 'private' mean? i am referring specifically to what is in the codeigniter 3 manual for how to prevent methods in a controller from being publicly available. is there something else that bears on this and if yes please explain or link to a source so we can understand what you are referring to.
https://codeigniter.com/user_guide/gener...te-methods

It is private because the "private" keyword is used, not because of the underscore.

It is private because the "private" keyword is used, not because of the underscore.

Isn't there some throwback though where you can do:

public function _myfunction() { }

And it won't be publicly accessible via the web browser because of the underscore?

It is private because the "private" keyword is used, not because of the underscore.

Isn't there some throwback though where you can do:

public function _myfunction() { }

And it won't be publicly accessible via the web browser because of the underscore?

Yes, as I explained - you can do that, but it's a legacy feature and "inaccessible" != "private".