Joomla! 4.0 or Next, Joomla! Platform or Framework, WTF is going on!?
A lot of discussion and confusion has been going on lately about the direction of the Joomla! project. What's in store for the CMS, what's going on with the Platform, why a new direction with the Framework, and how's all of this tie together. I personally don't have all of the answers, but what I can share is my own vision for the future and how everything ties together.
This is a guest post by Michael Babker
DISCLAIMER: In no way is this meant to represent the official stance of the PLT, this is just the opinion of someone who's contributed to making Joomla! better for everyone over the last three years and wants to continue doing so.
CMS 4.0 and Next
I've shared a vision with a few folks about how I would handle the future of the CMS, and with the new direction in the Framework, I think my vision is better defined. If I were in charge of development, I would "retire" the current CMS architecture at the EOL of the 4.x series, which is at the end of 2016. In 2014 when 4.0 is released, I would also release Joomla! Next, which is what I consider the next generation of the CMS, built fresh on the Framework. In keeping with our backwards compatibility policies, I would use 4.x as a transitional layer between the two applications. The goal would be that extensions would work between 3.5 and 4.x or 4.x and Next with little issue, but that promise can't be extended from 3.5 through Next. The Framework already has a compatibility layer in place to handle the class renaming to use PHP namespaces, so to me, this isn't a major issue. I would also make my damnedest effort to keep the existing extension infrastructure in place, as that is where Joomla! makes its money.
Places that still need to be thought through would include how to handle integrating the Framework into the CMS, updating the CMS code, and the MVC structure. My personal opinion on the matter is that the Framework in its newest form doesn't fit into the current CMS structure, hence the need for a different named product, even if it is the logical continuation of its predecessor. I'd also like the CMS to follow the Framework and embrace PHP namespaces (this could change the way class overrides are handled, possibly for the better, I'm still really learning and understanding namespaces). And as for the MVC structure, I personally think that we could use the best of both methods currently in the code and expand from there. For me, this means embracing the new JView interface (at a code level, I think child classes of this interface are easier to read and understand, and can be more easily reduced to the bare minimum, such as this example from the proposed CMS installer rewrite), dropping some of the legacy handling for finding and instantiating classes, and continuing to optimize and enhance the code infrastructure.
Next would be the awesome new product built fresh and keeping in mind the requirements of the CMS, and 4.x would be the immediate follow up to 3.5 and progress as developers see fit. An important aspect to keep in mind is that 4.x must be the glue to tie everything together. Without 4.x in this important role, then the transition to an updated infrastructure will fail. The time for open communication between the project and the development community is now to determine how to implement a plan like this and allow for developers to voice their concerns, if this is the plan we want to follow. Obviously, others have different opinions, and I truly believe we need to listen to those opinions and, as a team, come up with our plan on how to move forward.
Platform and Framework
To say that the Platform and Framework are one in the same would never be an accurate statement. Both started with a similar goal in mind; establishing a base framework from which developers could build upon. The biggest difference between the two is how they're moving forward. The Framework is doing a clean split from any CMS infrastructure, preferring to start off at the generic framework stage and allow it to be built upon by anyone, whereas the Platform started off as a copy of the /libraries folder from the CMS and retained a lot of that CMS specific code, which makes it difficult now to build on the Platform without using CMS specific concepts. It is for this reason I think the Framework will be successful.
As for the future, the plan is to reintegrate the existing Platform repository back into the CMS and allow the CMS to do with it as it pleases within its development strategy and guidelines. The Framework will grow on its own, without directly containing all of the technical needs that a CMS like ours does. This doesn't mean that we can't use the Framework in the CMS. As I said before, I feel that the current CMS architecture would have a difficult time integrating the Framework, but I fully believe that a modernized CMS can be built on the Framework, retaining the existing functionality we offer today, and in the long run, improving the user and developer experiences.
Fear, Confusion and Concern
Rightfully, there is some misunderstanding and fear amongst the community. As a project, we are continuing to evolve and exploring new development arenas. There are arguments that Joomla! as a project should only focus on the CMS or that Joomla! is only known as a CMS (see here and here); I personally argue that we should be willing to expand in logical ways, and that sharing our Framework follows that. Some argue that the Framework doesn't take into consideration the CMS's needs; I say that if the Framework is going to be usable outside the CMS, that it doesn't need to, and that the CMS is able to support itself and the code it requires. An example of this is in the JHtml package that wasn't transferred into the new Framework. The CMS will absorb it and continue to maintain it, developers will not lose that functionality, and if they need it for a project that uses the Framework without the CMS, they should be able to bring it (and its code dependencies) into their projects. A unified project roadmap would hopefully help calm some of these concerns and fears, but I truly believe that both the CMS and Framework have the best of intentions for their users in mind and the responsible parties for their code are willing to talk technical issues.
This is a guest post by Michael Babker
