The Joomla! framwork for which applications?

[Cyril Thibout]

Hi

It seems the communication on the Joomla! framework (platform?) has been quited down for a while now. Is the project sleeping or just evolving wihthout much noise ?

There are many companies that could use this framework to take advantage of the previous investments being made on the Joomla developpement efforts but can we use a product that seems dying (sorry to be harsh here) ?

thanks

Cyril

[Michael Babker]

Things are in some ways in maintenance mode right now and quiet.  There just hasn't been a lot of activity for the most part unfortunately, and it really died off with the license debate earlier this year.

--
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-frame...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.

[Lapoux Sébastien]

Thanks Michael.

Sorry not sure to understand you (with my poor english). About "it really died off with the license debate earlier this year", do you mean the Joomla platform is dead?

I believed that Joomla platform developer wanted LGPL licence to continue on it and it has been the case

 http://developer.joomla.org/news/582-lgpl-license-change-approved-for-the-joomla-framework.html

Thanks a lot for your clarification!

Sebastien.

[Michael Babker]

Momentum on developing with the Framework died off, not the actual project.  It's still somewhat active, there's been quite a few patches in many packages, and an occasional discussion.

--

[Johan Janssens]

@Michael : Too bad to hear that momentum has died off. I know from personal experience how hard it is to keep momentum going. I still hope that many of the framework improvements can make their way into Joomla. Happy to help with that, just let me know.

@Cyril : I don't want to hijack this thread, but if you are looking for a extension framework for Joomla, check our Nooku, http://www.nooku.org/ We released the 2.0 version of the framework a month ago and are actively maintaining it. Documentation is being worked on, with more guides being added on a weekly basis. 

Cheers,

Johan

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsub...@googlegroups.com.

[Cyril Thibout]

Thanks for your answers

They confirm what I was afraid of. I saw the opportunity to separate Joomla between the CMS layers and Framework layers died somehow but still hope the project of a full PHP framework on pair with Zend or Symfony is still active.

@Johan: Thanks for the link but I'm much more interrested in a general PHP framework than 'just' (sorry) a Joomla extension framework.

It's too bad that with all the sophistication of the Joomla code we can't bring to life a real PHP dev framework. It would be waaaayyyy simpler if we could share the knowledge between the  websites and applications projects with almost the same people in the company.

It would also help Joomla! in its race with other CMS. Look at all the buzz that Drupal did on Symfony which reinforced the position of Drupal for large companies. 

Cyril

[Michael Babker]

It's hard to do on my own (or with the couple people that have an interest), but the Framework isn't completely dead yet.  There's just no interest (visibly), from the leadership down, within the community and externally the interest has never been generated.  I still want to see it succeed, but I am seriously concerned it is a losing fight.

--

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-frame...@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-framework.

--
- Michael

Please pardon any errors, this message was sent from my iPhone.

[Cyril Thibout]

We could address a much broader audience if the framework was completed. There is no equivalent with Wordpress or Drupal. The code of Joomla is already a framework but for the CMS only.

What about a crowfunding campaign ?

[piotr_cz]

Many developers like to have newsest and smartest toys available and this may not be possible for a framework that's been built so tightly coupled with product like CMS which has strong backward strategy. The LGPL debate showed how conservative the CMS part is.

Other thing is that lots of solutions that Joomla framework just tackled are already available elsewhere. Reinventing the weel, learning best practices from scratch is counterproductive.

Last thing that might be putting people off is that JF is very unopinionated and while I see pros, this may be too much for beginners or for building a foundation for sharing packages.

I believe the composer integration in CMS may move things forward.

https://github.com/joomla/joomla-cms/pull/3617

[Cyril Thibout]

OK

then, should this mean we should thing the other way: how Joomla 4 could be built on top of Symfony or Zend ?

cyril

[Michael Babker]

0I see things differently with regards to the reinventing the wheel piece.  Most of the Framework code was extracted from the CMS and is the same code powering it, just namespaced.  The Event and Profiler packages saw some larger refactoring, but that's really it.  In the time since the 1.0.0 tag, different packages have grown a bit in terms of their features (see the Registry package for example) in ways they wouldn't have if they were still attached only to the CMS.  So, there have been some benefits to our own code base.

Truthfully, since we have Framework 2.0 to work with for the LGPL change, it's a chance to (in essence) break some of the compatibility with the CMS and try to evolve the code, in terms of what's offered and in terms of cleaning up our own architecture.  https://github.com/joomla-framework/language/pull/7 doesn't change anything in terms of features but goes a long way in modernizing code architecture, little things like that should help marketability in my opinion.

The Framework is stuck in a bad place right now without a real identity or a lot of real support for it.  The LGPL debate was the first time a lot of people probably took notice that it even existed (which in all fairness, the first stable tag was only 2 months before that).  It showed that CMS developers either don't want to use it or believe in the principle that everything under the Joomla flag has to be GPL and won't use it otherwise, so it has low marketability to Joomla's existing userbase.  Joomla still fights an uphill battle beyond our small circles because of perceptions a lot of folks have from the last time they looked at our code or the project as a whole 3-5 years ago.  So the name has really been a struggle.  Some people suggested that the Framework takes a different name on, but to me that hurts the Framework too; a new name suggests new code (the Framework isn't new, much of it dates back to Joomla! 1.5 in some form) or that the Framework team intends to fork away from the Joomla! project and community to do their own thing (which there are some who would actually prefer that I think as they see the Framework as competition for developer time toward the CMS).  So you have a code base that has very little support in the community it originated from, a project that isn't viewed as favorably as we would like externally, and the developers who support the Framework fading out of the picture.  It's doomed to go nowhere in those conditions.

Last thought with regards to building the CMS on existing Frameworks; it's been an uphill battle for me personally just to convince people there's valid reasons to namespace our code, make it distributable separate from the CMS, or modernize the code architecture by refactoring different pieces.  This is just with our own code base.  I'm not sure I'm ready to fight a battle about introducing third party code into the CMS as the foundation of the application.

[Adam Bouqdib]

That's really sad! I was super excited when the Framework first launched and was going to get my hands dirty but then ended up having so much work I didn't even contribute what I had promised. I am currently using it on one project but even that has had to be on the back-burner due to other work. I definitely think it's the way forward to separate the framework from the CMS though and use composer to manage dependencies as it would greatly benefit both Joomla extension developers and people writing standalone apps if it was just one codebase.

Is there anything that could be done to help push this?

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsub...@googlegroups.com.

[Rob Stocker]

Joomla is a brand, largely run by OSM.

I have watched the brand and legalese dominate Joomla's identity.

Frameworks are out, libraries are in. 

Composer is the way to go.

When a developer suggested (here) using Symfony's httprequest thingy it was suggested (rudely) that he go use Drupal.

Two many forks: mojambo, nooku, F0F (both of code and talented devs). A disproportionate amount of genuinely upset developers.

Seriously:  asking the CMS community about LPGL (could osm not show leadership and simply make the right choice.(instead of worrying about branding all the time). We almost had a framework that was not LGPL. What a ridiculous notion.

So when did joomla jump the shark?

I have a system using Joomla CMS and the old original platform (the framework is going to end up in the same state as the platform and this really pisses me off). I am slowly refactoring the system to use composer.

I want to use Joomla MVC style on top of Doctine,Composer and Symfony httprequest thingy.

I am only a medium coder - not a lead developer by any means yet I know this is the way to go. This is the word on the street.

The biggest drawback for me adopting Drupal (pre 8) was the idiosyncratic way they did everything. Learning Drupal meant making a choice. Drupals methods/skills were not transferable elsewhere: procedural code, info files etc. Now they are using yaml files, symfony base, twig. All these skills can be used elsewhere.

Now it is Joomla that will be the ones that do things so differently. With a decline in lead devs , accessing the progress made by ones peers in the php-Fig group is a no-brainer.

But then you have a set of useful components and less of a brand, better for devs (which in long run is better for cms), not better for OSM

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-frame...@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-framework.

--

Rob  - EMC23
085 843 3282
in...@emc23.com
www.emc23.com

[Johan Janssens]

@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 

Wikipedia : http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

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 : 

Wikipedia : http://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern

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

[Rigó Tamás]

help me to understand. Today, if someone wants to start a Joomla component development, Nooku will be the only or even be another way to go

 

Tamas

--

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.

[Michael Babker]

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?

[Rob Stocker]

Michael +1

[Anibal Sanchez]

Hi Tamas,

I have checked several Joomla frameworks for extensions development. Right now, I'm developing based on FOF https://github.com/akeeba/fof. In Feb 2003, I wrote this group message with my conclusions at that time: https://groups.google.com/d/msg/joomla-dev-general/BB-5eLwMdw4/KutsSgNTLZ4J

Nooku, S2, and Zoo were options at that time. Since then, I have adopted the simplest alternative (just a Joomla library), supporting a great model. Plus, a focus on stability and backward compatibility.

Bests,
Anibal

[Anibal Sanchez]

Hi Michael,

You have a great vision, and your ideas are sound.

However, from my view, when I tried to implement a simple application with Joomla! framework, it was a non-starters task. At the end, I dropped the project and implemented it with an alternative. My conclusion was that it was not ready for prime time, it had future, but it required several iterations (2-3 years) and great deal of documentation.

Concerning to the next generation of the CMS, after 10 years of evolution, Joomla has a whole mindset by itself and big heritage. A classic innovator dilemma (http://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma), where every idea is too small to be implemented, and any new feature has to pass the scrutiny of the community. I think Joomla! framework (and the previous Joomla! platform... trying to be created inside the CMS itself) have had the burden of the "next generation".

If I have to bet on the next big thing, I would think in a small pet project, running from behind, for instance Yoo's Pagekit (Zoo and Widgekit inside) looks promising so far and I am planning to test the first stable release :-D.

All the best,
Anibal

[Rob Clayburn]

My thoughts on how to build joomla 4... We should not be focusing on code. The code is produced once a vision is created and stakeholders sign up to that vision.working on the framework before that vision becomes a consensus will always be frustrating as there will always be a discordance between what is created and what is needed.
that being said .....

Any way to reduce scaffolding for 3rd party devs to me is a key area to focus on. So routing and an oppinionated mvc structure is a good start. I'd ditch jform and jtable personally I find them too limited.
As a 3pd I'd want to be able to specify a config file per view and have the framework build a default crud interface for me using 0 code. I want to have my data model accessible via a rest api which users can authenticate against. Basically we should make it a no brainer for a dev to install joomla (what ever form that ends up being) and to quickly create results whilst easily allowing overriding of the default behaviors and views

[Johan Janssens]

Hi Michael,

I have put my answers in between :

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?

Not sure if this is the right question to start with. I would prefer to start with a definition of a problem and then see what the best approach is. By narrowing down the problem, you can bring focus. 

 

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.

Don't see why not, but we both know CMS 4.0 is far off and the scope is very unclear. I rather focus on incremental change, if at some point you made so much change your rather call it 4.0 you can. This is how we went from 1.1 to 1.5. We did so much it made more sense to call it 1.5. 

 

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.

 

Starting with the MVC layer is a good step. The MVC implementation and CRUD implementation forms the basis of most components, the easier and more convention based this works, the easier it will be for people to write their own components.

Nooku : In Nooku we have come a long way to improve upon this. Nooku implements a default CRUD flow that works completely out of the box. It's possible to create a working MVC triad with just a database table and a few lines of code to dispatch it. Resullt : a completely working JSON REST service. The http dispatcher takes care of translation the HTTP methods to controller actions. JSON output is based on http://jsonapi.org/ standard as also used in EmberJS data 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.

 

Improving JTable is a good idea. JTable only implements a table gateway pattern, it doesn't provide a row/entity abstraction. Adding that would be beneficial as a step towards a more cohesive ORM solution. 

Nooku : In Nooku I build a new database layer that implements both a row and table gateway pattern. Nooku has database, table, rowset, row and query objects. See : https://github.com/nooku/nooku-framework/tree/master/code/libraries/koowa/libraries/database

On the model layer Nooku also provides an entity framework. Entities are implemented using a composite pattern. See : https://github.com/nooku/nooku-framework/tree/master/code/libraries/koowa/libraries/model/entity The framework has core entities to represent a row and rowset.  Components can easily create your own entity types, for example a file/folder entity etc.

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.

Correct, technically speaking it can be removed, the module and page head handling can be implemented using template filters which gives for a cleaner rendering pipeline. This also streamlines cache handling and solve some of the page cache issues.

Nooku : In Nooku I have implemented a view layer. The view layer has support for following format : html, json, rss, vcard, csv. The html format makes use of the template layer to render templates. See : https://github.com/nooku/nooku-framework/tree/master/code/libraries/koowa/libraries/view The JSON format works out of the box, if you connect it to a model is can render the model data as JSON. More info : http://guides.nooku.org/json.html

The template layer implements a complete template engine with support for : tags, functions, helpers and filters. It also offers an abstraction layer for other template engines with out of the box support for Twig, Mustache and Markdown. See : https://github.com/nooku/nooku-framework/tree/master/code/libraries/koowa/libraries/template One of the cool features is that it's possible to use different formats interchangeably in templates.

Nooku implements it's own 'page' template which is rendered without using JDocument. We use this to render pages that do not need to be rendered inside the Joomla template, instead of tmpl=component. The page template shows how we use template filters to inject assets and head information into it. https://github.com/nooku/nooku-framework/blob/master/code/libraries/koowa/components/com_koowa/views/page/tmpl/koowa.html.php

 

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.

I wouldn't necessarily drop it, instead I would implement a DI below and make JFactory implement that. This gives you 100% backwards compatibility. You do indeed still need a singleton to get your DI. Chicken or the egg problem. No way around that.

Nooku : In Nooku I have build an object manager which implements both decency injection and a service location pattern. By combining both I can use the benefits of both without the drawbacks. Since each object in Nooku extends from the same base object, the object manager can instantiate any object from anywhere. See : http://guides.nooku.org/essentials/object-management.html

 

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. 

I'm sceptic about this approach. "The best solution is found in the best definition of the problem". 'Develop a framework to be a strong toolset for a next generation CMS to be usable beyond Joomla' is not really a problem, more a vision. This is not different to what the platfrom and framework tried to do and this failed.

If there is anything that we can learn from 10 years of Joomla is that nothing 'next generation' has happened and is is likely to happen. Joomla isn't much different from Mambo, the core principles are still very much the same. 

I would rather look at some of the architectural problems that Joomla has today and how you can solve them in a BC way to make live easier for extension developers. For users I would like to look at making things more simple again, and that means talking a about what to remove not what to add.

 

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. 

Are those packahes solving problems the CMS has ? If not, just remove them. 

 

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.

Is this really a problem Joomla should try to solve ? 

 

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

Anything can be done. "Deciding what not to do is as important as deciding what to do" - Steve Job. If today you had to pick one of the above items - to start working on tomorrow - which would it be ? Why ?

Johan

 

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsub...@googlegroups.com.

[Michael Babker]

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?

Not sure if this is the right question to start with. I would prefer to start with a definition of a problem and then see what the best approach is. By narrowing down the problem, you can bring focus.

It doesn't necessarily need to be the first question, but to me it is a question that should be answered at some point.  Has the Framework gone so far "off course" with what people want the CMS to do (and there are mixed opinions on that too, ranging from cries to stop adding features or trying to decouple extensions to looking at the architecture of the whole application stack) that none of the efforts the Platform/Framework produced are usable, or are there pieces that can be used?  In terms of practicality to the CMS, some of the larger changes include refactored Event and Profiler packages and the Framework electing to deprecate the Log and Session packages, beyond that most of the remaining code is fairly close in structure and feature list to the comparable CMS classes.  And there is the obvious difference in class organization between the two groups with one being namespaced; is namespacing something that should be considered in the CMS, and if not do we un-namespace code that has already been to fit back into the CMS architecture?

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.

Don't see why not, but we both know CMS 4.0 is far off and the scope is very unclear. I rather focus on incremental change, if at some point you made so much change your rather call it 4.0 you can. This is how we went from 1.1 to 1.5. We did so much it made more sense to call it 1.5.

I'm in a spot right now where I want to focus on both short-term and long-term.  In the short-term, the project is reaching a point where for the first time in four years it will have a single actively maintained release series and we have promised a support period as long as the lifetime of 1.5, so how do we continue to innovate in the active series without breaking compatibility in releases or stagnating development?  The roadmap we published earlier this year certainly offers some ideas, but there's always more that can be done, especially as we begin to identify what the next major release will look like and how we can introduce a forward compatibility layer into the current series to assist in making adoption for the next series easier.  As far as the long-term goes, I know that there is probably 2 or 3 years before we see a 4.0 release and I'd like to see ideas getting tossed around now and concepts start coming together for it sooner than later.  My hope is that being able to have open discussions about where we as a community want to see the next release go would help to identify focus points and changes, both incremental and breaking, that could be incorporated into the appropriate development branch.  What I'd like to not see happen again is that the branch for the next major release is established 6 weeks before the scheduled beta and a hurried rush to merge patches be made to throw a release together.

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.

 

Starting with the MVC layer is a good step. The MVC implementation and CRUD implementation forms the basis of most components, the easier and more convention based this works, the easier it will be for people to write their own components.

Nooku : In Nooku we have come a long way to improve upon this. Nooku implements a default CRUD flow that works completely out of the box. It's possible to create a working MVC triad with just a database table and a few lines of code to dispatch it. Resullt : a completely working JSON REST service. The http dispatcher takes care of translation the HTTP methods to controller actions. JSON output is based on http://jsonapi.org/ standard as also used in EmberJS data layer.

I see a lot of Symfony in your dispatching and controller code.  IMO that's an area they shine in.  It actually works rather well once you have it implemented right, and from what I can see in the Koowa libraries it looks like all the generic stuff is covered well.

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.

Correct, technically speaking it can be removed, the module and page head handling can be implemented using template filters which gives for a cleaner rendering pipeline. This also streamlines cache handling and solve some of the page cache issues.

Nooku : In Nooku I have implemented a view layer. The view layer has support for following format : html, json, rss, vcard, csv. The html format makes use of the template layer to render templates. See : https://github.com/nooku/nooku-framework/tree/master/code/libraries/koowa/libraries/view The JSON format works out of the box, if you connect it to a model is can render the model data as JSON. More info : http://guides.nooku.org/json.html

The template layer implements a complete template engine with support for : tags, functions, helpers and filters. It also offers an abstraction layer for other template engines with out of the box support for Twig, Mustache and Markdown. See : https://github.com/nooku/nooku-framework/tree/master/code/libraries/koowa/libraries/template One of the cool features is that it's possible to use different formats interchangeably in templates.

Nooku implements it's own 'page' template which is rendered without using JDocument. We use this to render pages that do not need to be rendered inside the Joomla template, instead of tmpl=component. The page template shows how we use template filters to inject assets and head information into it. https://github.com/nooku/nooku-framework/blob/master/code/libraries/koowa/components/com_koowa/views/page/tmpl/koowa.html.php

This is an area Joomla really needs to step up and shine in.  Not quite sure I've fully grasped this part yet but it looks promising.

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.

I wouldn't necessarily drop it, instead I would implement a DI below and make JFactory implement that. This gives you 100% backwards compatibility. You do indeed still need a singleton to get your DI. Chicken or the egg problem. No way around that.

Nooku : In Nooku I have build an object manager which implements both decency injection and a service location pattern. By combining both I can use the benefits of both without the drawbacks. Since each object in Nooku extends from the same base object, the object manager can instantiate any object from anywhere. See : http://guides.nooku.org/essentials/object-management.html

In the context of Joomla, something like JFactory would always be a requirement.  It isn't the best implementation, but the Factory object I'm using in my latest personal project is at https://gist.github.com/mbabker/0370d599ebfa5ed941f6 and that is instantiated with the application after my DI Container has been set up with my base services.

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. 

I'm sceptic about this approach. "The best solution is found in the best definition of the problem". 'Develop a framework to be a strong toolset for a next generation CMS to be usable beyond Joomla' is not really a problem, more a vision. This is not different to what the platfrom and framework tried to do and this failed.

If there is anything that we can learn from 10 years of Joomla is that nothing 'next generation' has happened and is is likely to happen. Joomla isn't much different from Mambo, the core principles are still very much the same. 

I would rather look at some of the architectural problems that Joomla has today and how you can solve them in a BC way to make live easier for extension developers. For users I would like to look at making things more simple again, and that means talking a about what to remove not what to add.

Joomla really needs to step up and address a lot of the architectural issues, and some of them may not be BC.  For example, why does our MVC layer today have support for different controller classes based on the output format (like our controller.json.php files)?  I'd rather this be dropped and controllers rewritten to work out of the box regardless of format.  I'd like to see JError either killed off or reworked to be a useful error handling system; what it is today doesn't fit into that generalized description.

I'd also like for Joomla to not be a one-trick pony with its code (or code written for it) only being usable in a Joomla environment.  It's true that users are still searching for full scale applications that will meet their demands with the simplest maintenance requirements possible, but developers aren't always implementing these applications anymore.  Is Joomla's target market geared so much toward the end user looking for that easy to use application that we aren't trying to entice developers to use our platform, either by deploying the full CMS application or using parts of our API?

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. 

Are those packahes solving problems the CMS has ? If not, just remove them.

Truthfully, much of that code never solved a CMS issue but predated a time when SDKs were prevalent on the marketplace.  From what I can tell, our GitHub package is one of the few PHP packages wrapping their API with full coverage.  Our Mediawiki package could be useful in the CMS if we were to build a stronger bridge to our docs wiki.  Other packages though are at best developer resources.

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.

Is this really a problem Joomla should try to solve ?

Is it Joomla's responsibility?  No.  Is it something that interests me as someone who is willing to look beyond the CMS and see how Joomla code could be implemented in new ways?  Yes.  In many ways, the API is already there to support applications running in parallel (in theory the minimum you'd need is a separate index.php like file; application, menu, routing, and pathway classes; and register your application through JApplicationHelper::addClientInfo()) but it isn't a feature that most either realize is present or would be willing to write code for.

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

Anything can be done. "Deciding what not to do is as important as deciding what to do" - Steve Job. If today you had to pick one of the above items - to start working on tomorrow - which would it be ? Why ?

Truthfully, I couldn't pick one.  One of my downfalls has always been not being able to focus on one thing for an extended period because I'm always wanting to try something new or do more with what I already have.  It took me two years to tag a stable version of my code wrapping the Transifex API for no other reason than I would continue refactoring internals or trying to do things better and not wanting to constrain myself by SemVer style rules.

[Eric Fernance]

I've sat on replying to this email for a while.

I for one think there is definately a place for the framework. I have used the framework to build a complete project and also used a number of the packages as components in other projects. In fact I would go so far to say that many of the packages (forms, github, oauth) are some of the best written and best documented packages I have seen.

I would hate to see the framework die or just limit itself to something only used by the cms. I think it can be a great tool for people with experience with the cms to build full applications.

Personally I feel the biggest barrier to entry to working with the framework as a whole is how unopiniated the framework is. Don't get me wrong I believe that being unopiniated is a great benefit but it makes it hard to get started. I know the first time I tried to write something it took me a while just to get the app routing and startup correct.

If it is decided there is a future in the framework I would be happy to try and build up some tutorials and starter templates / boiler plates for the wiki as well as working on consolidating some of the docs. Code ignitor for example has great documentation.

any other thoughts or feedback? I would hate to see this project and the great code created so far die or fizzle.

Eric.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Johan Janssens]

Hi Michael,

I picked a few of the questions you raised, the rest of my comments I have put in between.

1. Has the Framework gone so far "off course" with what people want the CMS to do ?

Good question, the fruit of the work done in the framework depends on the ability to use the framework code in Joomla. It can be argued that the framework can be used outside of the cms scope, but as we both know there are too many better alternatives already.

The only possible way to answer this question is try to refactor some of the framework code back into the CMS and see if it still fits while maintaining backwards compatibility. If it does the answer is : "no it hasn't gone to far off course".

2.  Is namespacing something that should be considered in the CMS, and if not do we un-namespace code that has already been to fit back into the CMS architecture?

A debate over namespacing will draw away focus to move code from framework into CMS. Question is what comes first ? Or better said is namespacing a problem that needs to be solved before code from framework can be used inside the CMS. If the answer is no, then best approach is to un-namespace and use existing conventions using prefixes.

3. How do we continue to innovate in the active series without breaking compatibility in releases or stagnating development?

By adding incremental and fully compatible changes. Instead of using an approach to replace, use a approach of deprecation and legacy. 

With 1.5 we moved all our legacy into the so called legacy layer which was nothing more then a plugin you could turn on or off. While technically having it enabled didn't have much effect - to our own surprise - people started to demand developers to run without "legacy mode". The market regulated itself from there.

FOF, RedCore, Nooku and others show that it's perfectly possible to keep 100% compatibility with Joomla core while providing heaps of innovation and progress. To do that, you don't need to replace existing core code, instead you add new code, and deprecate the old.

Inspiration can also be drawn here from EmberJS and their 2.0 strategy which focusses heavily on stability and progress without stagnation. 

- http://readwrite.com/2014/11/04/emberjs-javascript-framework-we-dont-need-to-break-the-web

- https://gist.github.com/tomdale/45c6eaf2e00f11756f3a

Rest of the comments are in between from here

On Sunday, October 26, 2014 4:30:41 PM UTC+1, Michael Babker 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?

Not sure if this is the right question to start with. I would prefer to start with a definition of a problem and then see what the best approach is. By narrowing down the problem, you can bring focus.

It doesn't necessarily need to be the first question, but to me it is a question that should be answered at some point.  Has the Framework gone so far "off course" with what people want the CMS to do (and there are mixed opinions on that too, ranging from cries to stop adding features or trying to decouple extensions to looking at the architecture of the whole application stack) that none of the efforts the Platform/Framework produced are usable, or are there pieces that can be used?  In terms of practicality to the CMS, some of the larger changes include refactored Event and Profiler packages and the Framework electing to deprecate the Log and Session packages, beyond that most of the remaining code is fairly close in structure and feature list to the comparable CMS classes.  And there is the obvious difference in class organization between the two groups with one being namespaced; is namespacing something that should be considered in the CMS, and if not do we un-namespace code that has already been to fit back into the CMS architecture?

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.

Don't see why not, but we both know CMS 4.0 is far off and the scope is very unclear. I rather focus on incremental change, if at some point you made so much change your rather call it 4.0 you can. This is how we went from 1.1 to 1.5. We did so much it made more sense to call it 1.5.

I'm in a spot right now where I want to focus on both short-term and long-term.  In the short-term, the project is reaching a point where for the first time in four years it will have a single actively maintained release series and we have promised a support period as long as the lifetime of 1.5, so how do we continue to innovate in the active series without breaking compatibility in releases or stagnating development?  The roadmap we published earlier this year certainly offers some ideas, but there's always more that can be done, especially as we begin to identify what the next major release will look like and how we can introduce a forward compatibility layer into the current series to assist in making adoption for the next series easier.  As far as the long-term goes, I know that there is probably 2 or 3 years before we see a 4.0 release and I'd like to see ideas getting tossed around now and concepts start coming together for it sooner than later.  My hope is that being able to have open discussions about where we as a community want to see the next release go would help to identify focus points and changes, both incremental and breaking, that could be incorporated into the appropriate development branch.  What I'd like to not see happen again is that the branch for the next major release is established 6 weeks before the scheduled beta and a hurried rush to merge patches be made to throw a release together.

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.

 

Starting with the MVC layer is a good step. The MVC implementation and CRUD implementation forms the basis of most components, the easier and more convention based this works, the easier it will be for people to write their own components.

Nooku : In Nooku we have come a long way to improve upon this. Nooku implements a default CRUD flow that works completely out of the box. It's possible to create a working MVC triad with just a database table and a few lines of code to dispatch it. Resullt : a completely working JSON REST service. The http dispatcher takes care of translation the HTTP methods to controller actions. JSON output is based on http://jsonapi.org/ standard as also used in EmberJS data layer.

I see a lot of Symfony in your dispatching and controller code.  IMO that's an area they shine in.  It actually works rather well once you have it implemented right, and from what I can see in the Koowa libraries it looks like all the generic stuff is covered well.

Code isn't based on Symfony though, they are similarities but that's as far as you can go really. Symfony doesn't shine at all in the area of dispatcher and controllers. Symfony only exposes a crude base controller through it's framework bundle.

The implementation is quite crude and looks more like an afterthought. No controller interface, no decoupling from the request etc which makes it nearly impossible to run Symfony as part of a proper HMVC architectture. In Nooku controllers and dispatchers are first class citizens of the architecture. 

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.

Correct, technically speaking it can be removed, the module and page head handling can be implemented using template filters which gives for a cleaner rendering pipeline. This also streamlines cache handling and solve some of the page cache issues.

Nooku : In Nooku I have implemented a view layer. The view layer has support for following format : html, json, rss, vcard, csv. The html format makes use of the template layer to render templates. See : https://github.com/nooku/nooku-framework/tree/master/code/libraries/koowa/libraries/view The JSON format works out of the box, if you connect it to a model is can render the model data as JSON. More info : http://guides.nooku.org/json.html

The template layer implements a complete template engine with support for : tags, functions, helpers and filters. It also offers an abstraction layer for other template engines with out of the box support for Twig, Mustache and Markdown. See : https://github.com/nooku/nooku-framework/tree/master/code/libraries/koowa/libraries/template One of the cool features is that it's possible to use different formats interchangeably in templates.

Nooku implements it's own 'page' template which is rendered without using JDocument. We use this to render pages that do not need to be rendered inside the Joomla template, instead of tmpl=component. The page template shows how we use template filters to inject assets and head information into it. https://github.com/nooku/nooku-framework/blob/master/code/libraries/koowa/components/com_koowa/views/page/tmpl/koowa.html.php

This is an area Joomla really needs to step up and shine in.  Not quite sure I've fully grasped this part yet but it looks promising.

Just an example to show you how we refactored away from using JDocument in a 100% compatible way while adding a lot more power under the hood. Our approach allows JDocument and our view pipeline to be used interchangeably.

 

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.

I wouldn't necessarily drop it, instead I would implement a DI below and make JFactory implement that. This gives you 100% backwards compatibility. You do indeed still need a singleton to get your DI. Chicken or the egg problem. No way around that.

Nooku : In Nooku I have build an object manager which implements both decency injection and a service location pattern. By combining both I can use the benefits of both without the drawbacks. Since each object in Nooku extends from the same base object, the object manager can instantiate any object from anywhere. See : http://guides.nooku.org/essentials/object-management.html

In the context of Joomla, something like JFactory would always be a requirement.  It isn't the best implementation, but the Factory object I'm using in my latest personal project is at https://gist.github.com/mbabker/0370d599ebfa5ed941f6 and that is instantiated with the application after my DI Container has been set up with my base services.

Factory a hardcoded DI, this is by design, as a dynamic DI created new challenges. The problem with a pure DI container is namespace collisions on the DI object identifiers (keys). A DI works if you have a relatively small amount of objects in your container, it fails if you have more, or if the object keys are defined at runtime. Technically you can consider J

Nooku solves this by using a standardised naming conventions for DI keys, we call them object identifiers. The DI itself is hidden quite deep inside the object manager and is not directly exposed. More info : http://guides.nooku.org/essentials/object-management.html

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. 

I'm sceptic about this approach. "The best solution is found in the best definition of the problem". 'Develop a framework to be a strong toolset for a next generation CMS to be usable beyond Joomla' is not really a problem, more a vision. This is not different to what the platfrom and framework tried to do and this failed.

If there is anything that we can learn from 10 years of Joomla is that nothing 'next generation' has happened and is is likely to happen. Joomla isn't much different from Mambo, the core principles are still very much the same. 

I would rather look at some of the architectural problems that Joomla has today and how you can solve them in a BC way to make live easier for extension developers. For users I would like to look at making things more simple again, and that means talking a about what to remove not what to add.

Joomla really needs to step up and address a lot of the architectural issues, and some of them may not be BC.  For example, why does our MVC layer today have support for different controller classes based on the output format (like our controller.json.php files)?  I'd rather this be dropped and controllers rewritten to work out of the box regardless of format. 

Agreed. This was never part of the original architecture of 1.5. Format specific controllers where added later, unsure why. The implementation of is plain wrong. A controller decides based on the format what view to render. The format is part of the controller context (request), the action is the same being 'render' or 'display'.

Note : This is the same reason why a controller per action is a bad idea. 

 

I'd like to see JError either killed off or reworked to be a useful error handling system; what it is today doesn't fit into that generalized description.

Agreed. Nooku solves this by standardising on using exceptions everywhere, we re-throw php errors and failures as exceptions. Error codes used are HTTP status codes, and if no code is given we fallback to 500. 

Exceptions are dispatched as events using a special event exception publisher. This allows any event subscriber to capture the exception and handle it, if no one handles it, it's being re-throw for PHP to handle it.

This makes exceptions very powerful mechanism. For example, we have a special event subscriber that acts on Unauthorized exceptions that are thrown. The subscriber will handle redirecting to the login screen and outputting the error message. Right now this is something that every component developer needs to handle himself. With Nooku this comes out of the box.

 

I'd also like for Joomla to not be a one-trick pony with its code (or code written for it) only being usable in a Joomla environment.  It's true that users are still searching for full scale applications that will meet their demands with the simplest maintenance requirements possible, but developers aren't always implementing these applications anymore.  Is Joomla's target market geared so much toward the end user looking for that easy to use application that we aren't trying to entice developers to use our platform, either by deploying the full CMS application or using parts of our API?

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. 

Are those packahes solving problems the CMS has ? If not, just remove them.

Truthfully, much of that code never solved a CMS issue but predated a time when SDKs were prevalent on the marketplace.  From what I can tell, our GitHub package is one of the few PHP packages wrapping their API with full coverage.  Our Mediawiki package could be useful in the CMS if we were to build a stronger bridge to our docs wiki.  Other packages though are at best developer resources.

Oki.

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.

Is this really a problem Joomla should try to solve ?

Is it Joomla's responsibility?  No.  Is it something that interests me as someone who is willing to look beyond the CMS and see how Joomla code could be implemented in new ways?  Yes.  In many ways, the API is already there to support applications running in parallel (in theory the minimum you'd need is a separate index.php like file; application, menu, routing, and pathway classes; and register your application through JApplicationHelper::addClientInfo()) but it isn't a feature that most either realize is present or would be willing to write code for.

True, no need to pursue this.

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

Anything can be done. "Deciding what not to do is as important as deciding what to do" - Steve Job. If today you had to pick one of the above items - to start working on tomorrow - which would it be ? Why ?

Truthfully, I couldn't pick one.  One of my downfalls has always been not being able to focus on one thing for an extended period because I'm always wanting to try something new or do more with what I already have.  It took me two years to tag a stable version of my code wrapping the Transifex API for no other reason than I would continue refactoring internals or trying to do things better and not wanting to constrain myself by SemVer style rules.

Thanks for being honest. This is one of the hardest things you need to learn as a developer - especially if you wish to lead an open source project - There are new things happening every day and they all sound cool. The ability to make hard choices is key to the further success of Joomla. Without that, you get what you have now, a little bit of everything that really fits nothing.

Johan

[jms]

On 5 nov. 2014, at 03:41, Johan Janssens wrote:

> Hi Michael,
>
> I picked a few of the questions you raised, the rest of my comments I have put in between.
>
> 1. Has the Framework gone so far "off course" with what people want the CMS to do ?
>
> Good question, the fruit of the work done in the framework depends on the ability to use the framework code in Joomla. It can be argued that the framework can be used outside of the cms scope, but as we both know there are too many better alternatives already.
>
> The only possible way to answer this question is try to refactor some of the framework code back into the CMS and see if it still fits while maintaining backwards compatibility. If it does the answer is : "no it hasn't gone to far off course".
>

We have introduced some modifications in the CMS which have not been ported to the Framework.
JM

[Johan Janssens]

Thanks JM for the info. 

I don't think the question is which changes from the CMS should be ported to the framework, but rather vice-versa, which code in the framework is useful for the CMS and can be ported without breaking BC. Any code that cannot be ported back is code bloat that should be removed. 

Again focus is key here. 

Johan

[klas berlič]

Hi,

please excuse me if I'm not using the right terms in bellow point, but in my opinion we need a bit more systematic approach to this thinking:

a) First decision to make -  is this house old to the point it needs to be rebuild from scratch or does it make sense to just add new rooms and restructure it? I would say first, but this needs to be a common decision by those willing to invest time/knowledge/resources to implement the decision.

b) Architecture - once we have settled on the a, we need a plan. You don't start building or rebuilding a house with the bricks and mortar, you start with a plan what you are going to build and software is no different. Here we must settle on the mutiple levels that are often mixed:

1) basic scope: Are we building just for the web or are we going wider. I would say focus on the web and leave the rest to the others. Going for all is going for nothing (see framework's fate)

2) basic application architecture - functional side of the application and its elements, how they work together to create a page, this is not to be mixed with the next point. This is what we call now components, modules, plugins etc...

3) higher level (web) framework architecture (if we go for web in 2 it would be web framework architecture) - is it going to be pure MVC or are we aiming for hMVC or even parallell MVC (I'll try to explain this in separate post once I have the mindmap drawn..) and related decisions.

4) low level framework for basic operations - materials to be used for implementation - are we going to build it ourselves or will we use one of the existing wheels like Symphony. I would say focus on2&3 and leave this to others.

c) Implementation - implementation plan all they way down to who will do what and when.

Regards,

Klas

2014-11-14 11:21 GMT+01:00 klas berlič <klas....@gmail.com>:

Hi,

please excuse me if I'm not using the right terms in bellow point, but in my opinion we need a bit more systematic approach to this thinking:

a) First decision to make -  is this house old to the point it needs to be rebuild from scratch or does it make sense to just add new rooms and restructure it? I would say first, but this needs to be a common decision by those willing to invest time/knowledge/resources to implement the decision.

b) Architecture - once we have settled on the a, we need a plan. You don't start building or rebuilding a house with the bricks and mortar, you start with a plan what you are going to build and software is no different. Here we must settle on the mutiple levels that are often mixed:

1) basic scope: Are we building just for the web or are we going wider. I would say focus on the web and leave the rest to the others. Going for all is going for nothing (see framework's fate)

2) basic application architecture - functional side of the application and its elements, how they work together to create a page, this is not to be mixed with the next point. This is what we call now components, modules, plugins etc...

3) higher level (web) framework architecture (if we go for web in 2 it would be web framework architecture) - is it going to be pure MVC or are we aiming for hMVC or even parallell MVC (I'll try to explain this in separate post once I have the mindmap drawn..) and related decisions.

4) low level framework for basic operations - materials to be used for implementation - are we going to build it ourselves or will we use one of the existing wheels like Symphony. I would say focus on2&3 and leave this to others.

c) Implementation - implementation plan all they way down to who will do what and when.

Regards,

Klas

--

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-frame...@googlegroups.com.