Hypothetical question: Joomla as CMS but using another framework

[Edric Navarro (enav)]

Hi there

I do like to know what do you guys think about the idea of use another framework like "Symfony Framework", "Zend Framework" "Laravel Framework" or any other well established framework and only focus on the CMS. Think about it:

• Joomla! community is not the biggest and most active right now
• We don't have to maintain or document the framework just the CMS
• Joomla will be able to reuse packages maintained by another communities 

I heard that Drupal is using Symfony some how, haven't got enough time to read about it in detail. I also read that Laravel is another Symfony module (whatever that means). 

For me personally the Joomla! biggest weakness is the poor documentation that have driven lots of developers away. I think that this idea of using a 3rd party framework could help alot

But again this is all hypothetical

Regards
Edric N

[Michael Babker]

It would be a major change that if not handled carefully would be as disastrous as the Joomla 1.5 to 2.5 migration was to the project.  Therefore, I don't see the core libraries being flat out replaced in full with just another framework in general.  With that said though, the Framework itself has been moving in a direction that makes bits and pieces of it interoperable with PHP projects (in part based on the various PSRs).  So things are moving in a direction where various pieces can work with tools of another framework rather seamlessly.

For reference, Laravel is a framework which is built using various Symfony components, but it is indeed its own framework with its own direction.  In fact, you'll see some influences and uses of Symfony in the Joomla code base as well.  Drupal 8 was a major rewrite which built directly on Symfony components (while still also keeping "Drupalisms" that make that application stack unique).

A few examples of why a flat out replacement would not work well:

Replacing the Joomla application classes with the Symfony HttpFoundation component is a major paradigm shift in how the application actually runs.  The Kernel's concepts are largely incompatible with what the Joomla application does, and it forces a restructure of components to fit the bundle logic.  To me there is very little that could be done to make this transition work in a way that it doesn't cause major disruption.  Not to mention that it also forces at least a session API migration and possibly the router; at least in the case of Symfony's router it is really designed moreso for static resources than the dynamic environment we have).

Replacing the Joomla database classes with Eloquent (as IMO that is probably the smoothest transition that could be made), while it could be made less disruptive by making our DatabaseDriver and Query objects act as wrappers to the Laravel package, still comes with a major paradigm shift and one I don't think Joomla could make in an efficient manner (it would also force major changes in the data schemas in use everywhere, except for maybe developers using FOF as its models are modeled very closely off the Eloquent design).

Joomla 4 starts using our DI container a fair bit.  In theory, any PSR-11 compatible container could be used if only the retrieval methods are relied on (get/has).  As it relates to setting data, this part isn't standardized across the ecosystem so pulling in different containers and being able to set resources into them would be difficult.  Likewise, different containers take different approaches to configuration (our's and Pimple are really designed as runtime containers where they get built "on the fly" with each request, then you have containers like Symfony's which is designed to be a compiled and static container and for our userbase and distribution models that option has a lot of possible issues).

The caching engine is something I've been toying with for well over a year to make it work with a PSR-6 or PSR-16 implementation.  Even if we got the storage handlers in a spot though where any PSR compatible library could be dropped in, there is still a layer of code in front of it that has a lot of Joomla specific logic that just isn't covered in the PSRs, which makes adopting a PSR compatible API pretty difficult (no matter what library were in use we would still be writing a fair bit of logic ourselves, nullifying the benefit of consuming a third party solution).

So, while it would definitely be better for us to be able to just use someone else's code and focus on what makes Joomla unique, unfortunately it is not something that I feel is really practical.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

[Todor Iliev]

That would be great but it will kill Joomla.

It will be better to minimize duplication of libraries. You should use proven third-party libraries instead developing similar ones.
For example, you should replace JLog with Monolog, JDate with Carbon, JDatabase with Doctrine.
You should also remove Facebook and Twitter libraries from the framework if you do not use them. If someone would like integrate Facebook features, they will find a way to install Facebook SDK to their website.

You have to do the core libraries (Framework and CMS) much more abstract. Everyone will be able to install the libraries to any framework via Composer.
For example...If I would like to do online store, mobile apps and web services...I will do the website based on Joomla.
I will do the web services using Laravel or Symphony. I will install many of the core libraries (JUser, JAccess, JRoles, Article, Contact, etc.) to those frameworks.
That will be really powerful because we will be able to use core classes in different context.

Furthermore, the external libraries be familiar to everyone because they are used in the popular framework. Monolog and thephpleague/flysystem are used in Laravel.

We cannot switch to other framework but we will be able to use the power of the popular framework for features that missing in Joomla.
We should use popular external libraries where we can and we should do the core classes much more abstract.