[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [jfw] Re: The Joomla! framwork for which applications?



Michael +1

On Fri, Oct 24, 2014 at 3:28 PM, Michael Babker <michael.babker AT gmail.com> wrote:
So I absolutely hate discarding the work people put into anything, especially when some of it is my own, so my question now is how can we salvage what has already happened?

The Framework lost focus trying to be a general one size fits all tool, and in doing that much of our code was dumbed down to basic interfaces which aren't anything special.  So can we refocus the work in the Framework and use it as a building tool for CMS 4.0?  I say yes.

How can this be accomplished?  Let's start with the MVC layer.  The interfaces can be retooled (or dropped completely, who knows what the answer should be) to be supportive of the CRUD operations that we have in the CMS and we can slowly work to re-establish that code at the Framework layer.

Next, after having spent some time working with Doctrine, I'd look at how we have structured JTable and see if we can retool that to provide a more data object like approach (when compared to Doctrine Entities) while still providing a basic layer of database operations.

I'd like to seriously look at the CMS' rendering platform and how JDocument could be retooled, or even replaced with something like Symfony's PhpEngine Templating.  Page output should be much easier to accomplish in multiple formats and having a strong View layer of our MVC coupled with a strong rendering platform will make it easier to provide our data in JSON, RSS, or HTML formats without some of the headaches that exist today.  Along with that, I'd decouple aspects of JDocument and JHtml from the rest of the platform; the rendering engine takes full responsibility for all aspects rendering, be it reusable snippets or asset management, and the backend architecture focuses in primarily on data retrieval and management.

I'd also suggest looking at how we can drop our singleton object storage with JFactory and move toward a Service Provider like environment.  Having built some smaller scale Framework apps, I've found one instance where a singleton has been beneficial for me and ironically that singleton is my Factory class which is storing a reference to my DI container.

With that, moving forward on refactoring (where practical) places in the platform which are statics to create a more object oriented API.  This was started with our unit testing sprint last week, and I think that move could help strengthen our APIs and improve the testability of them.

All in all, I feel like we can develop the Framework to be a strong toolset to build the next generation of the CMS on while still having the resources to be usable beyond Joomla.  We have packages that may not fit into the current CMS structure (like our third party APIs) that could be beneficial to the greater PHP community.  Likewise, I can see us reaching a point where it could be practical to run applications in parallel to the CMS to create a more fine tuned environment while still utilizing CMS services.  Imagine a web shop component running separate from the CMS, so it doesn't have some of the overhead of a standard CMS application cycle, but is still able to integrate with the CMS' user data, for example, to manage customer accounts.  Enabling that could be a huge boost for Joomla in terms of creating more fine tuned and performant applications and extensions.

Have I lost my mind yet or is this something that could actually be feasible?

On Thu, Oct 23, 2014 at 11:17 PM, Johan Janssens <jjanssens AT gmail.com> wrote:
@Cyril : For the record, Nooku is not coupled to only Joomla, it comes in two flavours, Nooku Platform, which is a complete web application platform and Nooku Framework, which is subset of the platform specifically for Joomla extension development. I have worked the past 5 years on Nooku and with the release of the 2.0 version we have accomplished what we set out to do, build an framework and architecture that run both on it's own and inside Joomla.

With that said, on the topic of the Joomla 'framework'  and the question and topic of this thread. I often read discussions like, lets just use Symfony. Or why don't we use Zend ? ... Most of those discussions are missing the point what Joomla and the joomla 'framework' is about.

What is the Joomla 'framework' ?

The Joomla 'framework' was created as part of Joomla 1.5 development effort in an attempt to modularise and decouple the codebase. Our goal was to offer a modular and documented core API for extension developers. From the original announcement :

"...Yes, it's true. Joomla! 1.1 will provide an entry into a modern codeset allowing Object Orientated development, with inbuilt internationalisation (multi-lingual support), a refactored core and, FTP extension installation. Put simply, core restructuring and modernisation of code all built on a robust framework which allows the developer more power and flexibility with less effort..."

"...The end goal for 1.1 is to present a flexible and powerful core framework that is fully documented and sets a new standard for all future Joomla! development. We are very excited about the work done in the past 12 weeks and have received encouraging feedback from third party developers. Joomla! 1.1 has been built with 3PDs in mind from the beginning...."

Note : Joomla 1.1 was renamed to 1.5 in April 2006 before the announcement of the first beta. See : http://www.joomla.org/announcements/release-news/1102-joomla-15-is-on-the-horizon-.html

A strategic decision we made for Joomla 1.5 was to focus 100% on improving Joomla's extensibility for developers. Joomla 1.5 brought only very few user feature changes, we actually took a way more then we added to increase simplicity for users. Our mantra for 1.5 was : "Make Joomla simpler for users and more flexible for developers".  

So what is the Joomla 'framework' as we envisoned it ? The Joomla framework is a set of PHP libraries that are specifically build to offer developers a robust API to extend Joomla. To do this those libraries implement specific architecture design patterns, this is what we call the Joomla 'framework'. 

What is an architectural design pattern ?

An architectural pattern is a widely recognised and reused solution to a recurring design problem in the field of software architectures. The concept of an architectural pattern has a broader scope than the concept of design pattern (Wikipedia) Most architectural design patterns aim to introduce inversion of control. For Joomla 1.5 we implemented 2 such patterns  :

1. MVC 


The MVC pattern is an architectural design pattern that allows separation of concerns. It allows to separate data from presentation and business logic in a so called three tier archirecture. In Joomla MVC is the preferred way to build components and modules. Joomla enforces developers to separate their code into, controllers, models and views (templates).

The MVC pattern was originally created by Trygve Reenskaug in the 70's and has since proven to be the pattern of choice for building web architectures. It works especially well in a component driven architecture, which Joomla, like Drupal and Wordpress are. 

Side note : Nooku builds further upon this architecture by implementing HMVC, or hierarchical MVC. This allows multiple components to work together during the same request/response cycle. Something I was never able to solve for Joomla 1.5. More info : http://guides.nooku.org/essentials/hmvc.html 


2. Publish/Subscribe : 


The publish/subscribe pattern is an architectural design pattern that implements a mechanism to deal with cross cutting concerns. In Joomla's it's implemented as part of the plugin and events API. Out of the box Joomla triggers various events that plugins can subscribe too (the system events). The event API can also be implemented by developers inside their own components and some core components do also implement their own events.

Side note 1 : Nooku builds further upon this architecture by implementing a DCI architectural pattern. In Nooku each tier in the MVC triad implements DCI and this brings out of the box inversion of control to Nooku components.

Side note 2 I wrote a white paper a while ago, on the topic of inversion of control in Joomla, and especially on the event and plugin API.  The paper contains some historic remarks, criticism and explains how Command Chains as implemented in Nooku can further Joomla's extensibility. 

Why Symfony or Zend is the wrong question ?

Frameworks like Symfony or Zend are library based. They offer re-usable libraries to developers to make common tasks easier, for example working with the http protocol, accessing a database, handling the file system etc.  They don't provide architectural design patterns. I common tongue : 'They are not opinionated'. 

Take Symfony for example, it markets itself as  : "Symfony is a set of reusablePHP components..." If you ask Fabien, he will tell you : "Symfony is a 'meta framework, a framework to build frameworks". 

Does that mean you shouldn't or couldn't use Symfony ? Not at all. Both frameworks deliver high quality re-usable libraries that can benefit Joomla, do they solve the 'framework' problem in Joomla ? No! Why not ? Because they do not provide architecture. For example Symfony is totally lacking an MVC implementation.

Why is Joomla Framework the wrong answer ?

The Joomla Framework evolved from the Joomla Platform which evolved from the Joomla 1.5 core. It's not focussing on improving the Joomla architecture through introducing or improving new architectural design patterns. It's actually not focussed on solving any Joomla problem at all. 

Instead the Joomla Framework has removed the architectural design patterns and introduced no alternatives. The MVC implementation as it's left in the Framework is little less then a set of very basic interfaces. The implementation is so thin its not usable at all.

For example : The model implementation in the framework has been reduced to a AbstractModel that only implements a getDb() and setDb() method. Same is true for the controller and view implementations. 

The rhetoric is that this should be left up to the application build on top. In Joomla's case the 'cms'. This makes the Framework nothing more then a set of interfaces, which are not even build against the needs of the 'cms'. 

The Framework is basically putting the world upside down. The Joomla architecture and framework API's should follow from the function they need to serve as part of the cms. Not the other way around. 

Towards more architecture and less core libraries

Joomla is defined by it's architecture, not it's core libraries. Joomla can definitely benefit from re-using other libraries, Symfony, Zend etc. It has always done that. Today the CMS includes 6 external libraries, previous versions even included more. 

In today's PHP world Composer makes it possible for Joomla components to define extra library dependencies and install them with ease. This delivers big benefits for developers. At Joomlatools we created a composer installer for Joomla that can install any extension and it's dependencies. Bringing Composer to any Joomla developer. 

However, Joomla still needs a strong architecture. The current 1.5 architecture is becoming 7 years old in January. It was build in a PHP 4.3 world. PHP and the web have evolved. If Joomla want's to keep up it's architecture will need to evolve too.  

Nor Zend, nor Symfony, nor anyone else can help with this. The architecture is what makes Joomla Joomla. Developing architectures for extensible web applications, like Joomla, Drupal, Wordpress is one of the hardest things there is. It trying to create something that needs to solve a problem that doesn't exist yet.


Conclusion

Joomla literally means "all together or as a whole". There are many ways that Joomla can be all together, starting with it's architecture. Everything that Joomla is grows and evolves from there. 

The Joomla 'framework' as we envisioned it in Joomla 1.5 has never been about building a general PHP framework - those frameworks exists, ... no need to re-invent them - The Joomla 'framework' is about creating an extendible web application architecture to make Joomla more flexible for the benefit of all. 

Johan


On Monday, October 20, 2014 11:47:47 AM UTC+2, Cyril Thibout wrote:
OK
then, should this mean we should thing the other way: how Joomla 4 could be built on top of Symfony or Zend ?

cyril

--
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.

--
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.



--
Rob  - EMC23
085 843 3282
info AT emc23.com
www.emc23.com

--
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.