GSOC14 MVC Project
One of the best things about Joomla is its constant drive to innovate whilst maintaining a strong and enthusiastic developer base. And the time has arrived for an important new development - the new Model, View and Controller classes for components.
We all have grown to know and love the current MVC classes since Joomla 1.5, but we also know it has many limitations:
- The code doesn’t allow HMVC to allow easy creation of modules
- The code is hard to learn often – there are many places we can make it easier for people to write less code when learning to write extensions for Joomla
- Logic is often mixed – our views often contain code that should be in the model or controller
The introduction of FOF into core reinforced many of these views that Joomla can make component (and module) development significantly easier than it is at present.
The new base MVC classes were introduced into Joomla 3.0 and into the platform as far back as 2011 (https://magazine.joomla.org/issues/issue-nov-2013/item/1580-new-mvc-for-joomla-cms, https://github.com/joomla/joomla-platform/pull/1120) and with the interfaces introduced gave a whole new flexability for CMS implementation.
Initially the new MVC classes into the Joomla Installer. Further work was then done by Buddhima Wijeweera in GSOC13 used these in com_config in conjunction with Elin Waring. An alterative proposal has also been made by Matthew Lenning (https://github.com/joomla/joomla-cms/pull/3503). My GSOC project this year will aim to build out these classes into classes that all extension developers can use bringing in the experience of my own 3rd party extension developing, research and building on the excellent work done by the aforementioned people.
I will soon be making posts about especially gathering feedback on probably the most controversial aspect of the new MVC classes – the single task controllers. Currently this works by calling controller.task in the URL. This allows you to have multiple tasks in a controller. However in the new MVC implementation this is not the case – to keep code clean and separate, we have just one task per controller. However this has a side effect on many large extensions where you could potentially need tens of controllers.
Making JTable more DRY and RAD
Over Easter I made a few proposals to improve the JTable class. This should make writing table classes easier – this just inserts some code commonly used across many core (and third party) extensions into the parent JTable class in order to make the code more repeatable.
There is also a RFC here https://groups.google.com/forum/#!topic/joomla-dev-cms/AiCOgamjQvQ about eradicating the need for JTable classes in simple cases introducing a (non-compulsory) table naming scheme for Joomla (please comment on the respective google group post and test the PR’s!!).