I am quite new in Joomla. I have now understood the components, modules, templates thing and can also build modules and simple components.

But the one thing that has always confused me in Joomla is the placement of methods in components. I studied a system and saw the save function being overridden sometimes in model and sometimes in controllers. The online solutions to queries also vary, some suggest to place methods in model whereas some say in controller. What I think is model should not be having such methods where some extra logic should be performed and it's the controllers job.

Or what pattern am I missing here in this regard, please enlighten me.

  • 1
    I think you will continue to encounter malformations in the MVC design pattern because Joomla developers come from all walks of life with vastly different understandings of coding practices. When you see something "in the wild" that doesn't look right, please speak up to the author. Good developers will always welcome tactfully delivered suggested refinements -- I know that I would appreciate such feedback. I'm not sure if your question is narrow enough to be succinctly answered on this site. Do you have a sample save() snippet to offer in your question so that an answer can be provided?
    – mickmackusa
    Jan 9, 2019 at 7:32

1 Answer 1


The comment from @mickmackusa is essentially correct, but there's some context missing, perhaps, from your question that makes me wonder if you're not asking a wider question. There are wide variety of reasons for the overrides you're seeing.

In an MVC world "save" is both a controller and a model method. It stems from the concept "separation of concerns." The model's concern is not interacting with the rest of the system; its concern is ensuring the data is valid and then persisting it.

When you interact with the system the controller will get the "save" request from you first, and it may have some housekeeping of its own to do before passing the request on to the model. If it does, then the controller's save method needs to be overridden to achieve that.

Another possible reason is because the form itself that has been submitted may contain data from (or data destined for) two different models. That's not "clean" from a pure coding standpoint, but we live and work in the real world, with real users, who don't want to deal with three different forms simply because that's a more efficient way to store the data -- a user's experience should never be as a slave to the database. In those cases the controller "save" task will ensure the data gets routed to the right model. This approach can happen if you build your system around the user's tasks, rather than the database tables. (I'm not commenting upon which is the better approach, because frankly it's not a clear-cut decision; there are cases when either is better than the other.)

Another cause for overriding the method is because the class itself doesn't follow the single-responsibility principle very well (directly related to the comment of "from many walks of life"). There are several methods that really should be broken up into 5-6 smaller methods; the large method gets overridden often because there is just one single line, sometimes only vaguely related to the task, that needs to be changed.

There's a school of thought called "skinny controller - fat model" that says everything to do with the data belongs in the Model, the controller is a glorified switchboard, simply making sure the model gets the data it needs. There are other schools that insist there need to be other classes around the model and controller that take care of the business logic; the controller controls and the model saves, and other classes do the other things. There's really never been an architect that said "this must go here" so we have what we have; a thousand different flowers blooming in the code. MVC has never been so rigidly defined that code can only be written in one manner to satisfy it (one of the early MVC approaches gave every single individual area on the screen its own controller, for example; I remember someone revived that idea a while back under the name "Hierarchical Model-View-Controller").

All that is by way of supplying context for this: There really isn't enough information in your question for you to get a concrete answer. When you see something in the code and you don't understand the why of it, ask a specific question about that piece. Maybe there's a good reason why the general rule doesn't apply in that case. Maybe the right answer is "Ooops. You're right. That doesn't belong there."

In which case, you may have just found your first opportunity to contribute to the project.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.