5.7 Architectural decisions / rants (PHP is not Java, etc.)
Permalink
Hearing these come up in a couple of separate threads so I thought it might be better to keep these in their own thread to avoid flooding other threads.
The idea of this thread is to shout out your opinions, praises, frustrations, or anything related to the new 5.7 architecture.
Disclaimer: I don't personally have much bad to say about the new architecture. All code changes over time. If the code is readable and understandable, I'm all in for it. I certainly think there are things missing from the current core but I'm trying to bring these up in the Git issues (like many others) as I notice them and have time to propose solutions for them.
I'll start by giving my own views on some of the topics I've seen a couple of times thrown in at the forums.
** Namespaces **
I strongly support this choice. If one line on top of a file gives us the benefits of autoloading, it's worth it. In the old way, we needed to load the class (library, model), EVERY time we needed it. Now we only need to define the namespace once.
** Simplicity vs. abstraction **
While I strongly support simplicity in code, abstraction comes many times with its benefits.
Today, much thanks to the IoC container, it is possible to override a helper from a package without adding any overriding files to the system. Just one example of the benefits of adding a level of abstraction in the .
However, in most other places I strongly vote for simplicity in code and architectural decisions, to keep the code understandable and readable. There should be a good balance between these two.
** IoC container **
Very good decision, this will be useful in many occasions.
So, let's hear them in this thread! What do you like and what do you hate? Feel free to shout out your own view reflecting your own preferences / background. Also feel free to shout out your opinions on the latest development in PHP and how it's been applied in the core.
The idea of this thread is to shout out your opinions, praises, frustrations, or anything related to the new 5.7 architecture.
Disclaimer: I don't personally have much bad to say about the new architecture. All code changes over time. If the code is readable and understandable, I'm all in for it. I certainly think there are things missing from the current core but I'm trying to bring these up in the Git issues (like many others) as I notice them and have time to propose solutions for them.
I'll start by giving my own views on some of the topics I've seen a couple of times thrown in at the forums.
** Namespaces **
I strongly support this choice. If one line on top of a file gives us the benefits of autoloading, it's worth it. In the old way, we needed to load the class (library, model), EVERY time we needed it. Now we only need to define the namespace once.
** Simplicity vs. abstraction **
While I strongly support simplicity in code, abstraction comes many times with its benefits.
Today, much thanks to the IoC container, it is possible to override a helper from a package without adding any overriding files to the system. Just one example of the benefits of adding a level of abstraction in the .
However, in most other places I strongly vote for simplicity in code and architectural decisions, to keep the code understandable and readable. There should be a good balance between these two.
** IoC container **
Very good decision, this will be useful in many occasions.
So, let's hear them in this thread! What do you like and what do you hate? Feel free to shout out your own view reflecting your own preferences / background. Also feel free to shout out your opinions on the latest development in PHP and how it's been applied in the core.
Couldn't agree more on your view on the documentation, I've also been mentioning it at least a couple of times.
But documentation has never been a strong point for concrete5. I remember starting up with 5.4.0.5, the situation wasn't any different. I needed to look a lot of things from the core if I needed to do anything even slightly more complex than turning an HTML template into a theme. And I can only imagine what the situation was in the prior versions.
Not saying that it is any reason to neglect documentation all over since there has never been a good one. Just saying that once you start to familiarize yourself with the core, it's much easier to understand anything after that.
But yes agree on your point. Documentation and available developer resources are the keys to success for any technical thing out there. There is a reason why most CMSes (including c5) have started using the Symphony components. And it's not solely the technical design or ideas behind it.
But documentation has never been a strong point for concrete5. I remember starting up with 5.4.0.5, the situation wasn't any different. I needed to look a lot of things from the core if I needed to do anything even slightly more complex than turning an HTML template into a theme. And I can only imagine what the situation was in the prior versions.
Not saying that it is any reason to neglect documentation all over since there has never been a good one. Just saying that once you start to familiarize yourself with the core, it's much easier to understand anything after that.
But yes agree on your point. Documentation and available developer resources are the keys to success for any technical thing out there. There is a reason why most CMSes (including c5) have started using the Symphony components. And it's not solely the technical design or ideas behind it.
The difference between the lack of documentation back at the start of 5.4 and the lack at 5.7 is that internally 5.4 was simple enough to learn by reading the code. Internally 5.7 is much more complex.
OK, I don't share your view on that. E.g. comparing the old dispatcher to the new dispatcher shows a lot of progress in terms of the startup process.
Sure, you'll need to dig one or two layers beyond that to find what you're looking for but I think the overall architecture is much more "clean" and better organized than it has ever been.
Sure, you'll need to dig one or two layers beyond that to find what you're looking for but I think the overall architecture is much more "clean" and better organized than it has ever been.
definitely agree with Johnthefish on this. From my point of view this has greatly increased the amount of time it will take me to get to grips with 5.7. I'm very time limited anyway so summoning up the mental energy to go through all of the changes is quite challenging. I know I'll get there but there was more immediate 'payback' with earlier versions
We're committed to getting better on documentation. If you haven't taken a look at the new developer documentation (which is only about 20% complete, it's definitely a work in progress) you really ought to:
http://www.concrete5.org/documentation/developers/5.7/...
It's going to be a lot better, more comprehensive and better organized than the older documentation ever was. In addition to all the topics that are there and that are pending we're going to include an Implementation Guide, which is a look at how developers might solve common problems with concrete5. This has always been lacking.
And apigen is much nicer api generation tool than we've ever used before.
http://concrete5.org/api/
It's not perfect and it's not finished, but the end result is going to be much better.
http://www.concrete5.org/documentation/developers/5.7/...
It's going to be a lot better, more comprehensive and better organized than the older documentation ever was. In addition to all the topics that are there and that are pending we're going to include an Implementation Guide, which is a look at how developers might solve common problems with concrete5. This has always been lacking.
And apigen is much nicer api generation tool than we've ever used before.
http://concrete5.org/api/
It's not perfect and it's not finished, but the end result is going to be much better.
To be honest. I think everything has been said and mostly by JTF. There is great merit in opting for the 3rd party frameworks which is why everyone and his dog has gone over to them. However, addon devs are not core developers so stop expecting them to be, I think is the message.
Much of the developer frustration with 5.7 is driven by a lack of documentation and explanation of the API (OK, stuff has just been published and it fills a few gaps, but there is so much more missing).
Every time an API issue is responded to we get a stream of references to the amazing 3rd party technologies used that soon blossom out across the internet. Are we getting real answers, or just swamped with partly relevant information? Even with time to read all that and filter out what appears to be relevant we don't get a clear picture. We don't know which parts of such are actually implemented in the core, which are implemented with modification, and which have been left out or are broken in a c5.7 conext.
In the PRB we are approving 5.7 submissions because they satisfy a few basic rules and appear to work. Not because they have been well built for 5.7. We could be approving complete hacks rather than well constructed addons that use the 5.7 architecture to its full and be none the wiser. These addons are then being used by others to learn and we end up with a 5.7 marketplace built on a game of Chinese whispers. Is that the best way to end up with a quality marketplace? Could that be one of the reasons why review contributions by many PRB members has tailed off to near zero since the initial 2-week burst of 5.7 enthusiasm?
If 5.7 fails in the overall CMS market it won't be because its buggy. It won't be because of annoying usability quirks. Every CMS has those to some extent. It will be because 99% of developers that used to be able to do stuff with 5.6 are fumbling in the dark with 5.7.