Request for Comments: Service Layer
260 views
Skip to first unread message
Chris Davenport
Jan 17, 2016, 8:29:52 PM1/17/16
to Joomla! CMS Development
One of the issues we're often faced with as developers is that our components, including the core components, do not have a clearly defined API. For example, if I want to retrieve some article data from the com_content component I could try instantiating one of com_content's controller or model classes, but this is often inconvenient as they frequently exhibit unwanted side-effects that can be difficult to overcome. Sometimes developers will even resort to reading or writing data directly to the database tables of another component. This is all very far from ideal, especially as the core component classes and database schemas are not subject to the backwards-compatibility promise inherent in our development strategy. In effect, if I attempt to use these classes or tables directly my code could break at any time.
Furthermore, there is increasing pressure to support "channels" that are different from the traditional web channel. For example, it is common nowadays to need access to data from a command line (CLI) program. Most component controllers are written on the assumption that they are being called from a web environment and odd behaviour can result from calling them directly from a CLI program. There needs to be some way of separating channel-specific code from other code, so that it becomes possible to use components across multiple channels reliably.
The introduction of a Service Layer [1] directly addresses these problems by supporting the definition of a component-level API that can be used across a variety of channels. The intention is that the core components might eventually be refactored to use the service layer and the API thus defined can be brought into the scope of the backwards-compatibility promise. By having a clearly defined API it becomes possible to extend or enhance the functionality of a component without fear that the additional functionality will break unexpectedly when the component is updated, at least for minor and patch updates (as defined by Semantic Versioning).
Although it's early days, this is also intended to be part of the migration strategy for moving extension code to Joomla 4.
The service layer also encourages the separation of "domain logic" from "infrastructure logic". Ideally, model classes should only contain logic that is part of the core functionality of an extension. Other concerns, such as sending out notification emails, should be handled elsewhere. This "other" logic, which doesn't have anything to do with the core "business rules" embodied by the extension, is often either orchestrating actions in the model (eg. assembling multiple actions in a transactional wrapper) and so belongs in the service layer, or is responding to events that occurred in the model (eg. sending out notifications after some item was saved) and so belongs in event handlers. For those who want to understand more about why adding a service layer could improve your code, there is an excellent video by Ross Tuck which provides an entertaining introduction [2].
I've made a stab at implementing a service layer for Joomla here: https://github.com/chrisdavenport/service and I'd like to get feedback and comments on it so far. Note that it is a standalone package and requires Composer to install it. This is not an end-user feature. At the present time there is a dependency on the League Tactician command bus [3] which has a PHP 5.5 minimum requirement. This will be dealt with (somehow) later.
As a demonstration of the effects of using a service layer, I have done an example refactoring of the com_contacts front-end using the service layer. There is a pull request [4] for it so that you can try it out. The PR includes a CLI program that uses the same service layer to perform the same functions available via the web. Unfortunately, com_contacts has almost zero functionality that could be considered "domain logic" so it's probably not a great example, but hopefully there's enough structure to give a flavour of what can be done with it.
Note that the service layer is optional and enhances the regular MVC structure without necessarily changing existing code in models and views. In most cases the principal impact will be on controllers and generally results in much simpler, slimmer controllers by shifting most of the logic into command, query and event handlers. More detailed documentation on what it does and how to install and use it can be found in the README [5]. This development is also significant in that it begins to introduce some tactical concepts from Domain-Driven Design [6] into Joomla, most notably Value Objects [7] and Domain Events [8].
The development of the service layer was partly motivated by the need to have a better means of integration with Joomla extensions in the web services project. It is my intention to write an integration layer for the web services code currently under development so that it becomes simpler to connect REST (and SOAP) services to Joomla components in the future.
What I need...
Feedback. Testing. Improvements. Unit tests moved to PHPUnit/CodeCeption.
If this can be improved to a reasonable level then the service layer will be considered for inclusion in the Joomla 3.6 release. Refactoring of the core components is probably something for a later release.
All comments welcome.
Chris.
[1] http://martinfowler.com/eaaCatalog/serviceLayer.html
[2] https://www.youtube.com/watch?v=ajhqScWECMo
[3] https://tactician.thephpleague.com/
[4] https://github.com/joomla/joomla-cms/pull/8747
[5] https://github.com/chrisdavenport/service/blob/master/README.md
[6] https://en.wikipedia.org/wiki/Domain-driven_design
[7] http://martinfowler.com/bliki/ValueObject.html
[8] http://verraes.net/2014/11/domain-events/
--
Furthermore, there is increasing pressure to support "channels" that are different from the traditional web channel. For example, it is common nowadays to need access to data from a command line (CLI) program. Most component controllers are written on the assumption that they are being called from a web environment and odd behaviour can result from calling them directly from a CLI program. There needs to be some way of separating channel-specific code from other code, so that it becomes possible to use components across multiple channels reliably.
The introduction of a Service Layer [1] directly addresses these problems by supporting the definition of a component-level API that can be used across a variety of channels. The intention is that the core components might eventually be refactored to use the service layer and the API thus defined can be brought into the scope of the backwards-compatibility promise. By having a clearly defined API it becomes possible to extend or enhance the functionality of a component without fear that the additional functionality will break unexpectedly when the component is updated, at least for minor and patch updates (as defined by Semantic Versioning).
Although it's early days, this is also intended to be part of the migration strategy for moving extension code to Joomla 4.
The service layer also encourages the separation of "domain logic" from "infrastructure logic". Ideally, model classes should only contain logic that is part of the core functionality of an extension. Other concerns, such as sending out notification emails, should be handled elsewhere. This "other" logic, which doesn't have anything to do with the core "business rules" embodied by the extension, is often either orchestrating actions in the model (eg. assembling multiple actions in a transactional wrapper) and so belongs in the service layer, or is responding to events that occurred in the model (eg. sending out notifications after some item was saved) and so belongs in event handlers. For those who want to understand more about why adding a service layer could improve your code, there is an excellent video by Ross Tuck which provides an entertaining introduction [2].
I've made a stab at implementing a service layer for Joomla here: https://github.com/chrisdavenport/service and I'd like to get feedback and comments on it so far. Note that it is a standalone package and requires Composer to install it. This is not an end-user feature. At the present time there is a dependency on the League Tactician command bus [3] which has a PHP 5.5 minimum requirement. This will be dealt with (somehow) later.
As a demonstration of the effects of using a service layer, I have done an example refactoring of the com_contacts front-end using the service layer. There is a pull request [4] for it so that you can try it out. The PR includes a CLI program that uses the same service layer to perform the same functions available via the web. Unfortunately, com_contacts has almost zero functionality that could be considered "domain logic" so it's probably not a great example, but hopefully there's enough structure to give a flavour of what can be done with it.
Note that the service layer is optional and enhances the regular MVC structure without necessarily changing existing code in models and views. In most cases the principal impact will be on controllers and generally results in much simpler, slimmer controllers by shifting most of the logic into command, query and event handlers. More detailed documentation on what it does and how to install and use it can be found in the README [5]. This development is also significant in that it begins to introduce some tactical concepts from Domain-Driven Design [6] into Joomla, most notably Value Objects [7] and Domain Events [8].
The development of the service layer was partly motivated by the need to have a better means of integration with Joomla extensions in the web services project. It is my intention to write an integration layer for the web services code currently under development so that it becomes simpler to connect REST (and SOAP) services to Joomla components in the future.
What I need...
Feedback. Testing. Improvements. Unit tests moved to PHPUnit/CodeCeption.
If this can be improved to a reasonable level then the service layer will be considered for inclusion in the Joomla 3.6 release. Refactoring of the core components is probably something for a later release.
All comments welcome.
Chris.
[1] http://martinfowler.com/eaaCatalog/serviceLayer.html
[2] https://www.youtube.com/watch?v=ajhqScWECMo
[3] https://tactician.thephpleague.com/
[4] https://github.com/joomla/joomla-cms/pull/8747
[5] https://github.com/chrisdavenport/service/blob/master/README.md
[6] https://en.wikipedia.org/wiki/Domain-driven_design
[7] http://martinfowler.com/bliki/ValueObject.html
[8] http://verraes.net/2014/11/domain-events/
--
Chris Davenport
Joomla Production Leadership Team
Joomla Production Leadership Team
Niels Braczek
Jan 17, 2016, 10:17:06 PM1/17/16
to joomla-...@googlegroups.com
Am 18.01.2016 um 02:29 schrieb Chris Davenport:
> All comments welcome.
Great approach! Just tweeted about it, to address a bigger audience.
Regards,
Niels
--
| New Stars on the Horizon: GreenCape · nibralab · laJoom |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
> All comments welcome.
Great approach! Just tweeted about it, to address a bigger audience.
Regards,
Niels
--
| New Stars on the Horizon: GreenCape · nibralab · laJoom |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
George Wilson
Jan 18, 2016, 5:35:15 PM1/18/16
to Joomla! CMS Development
Please work on the way you are using the DIC in your app. This is like a service locator (http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/) rather than a DIC.
Personally I also hate empty interfaces (https://github.com/chrisdavenport/service/blob/master/src/Command.php , https://github.com/chrisdavenport/service/blob/master/src/Event.php etc.)
Honestly I'm not convinced by the command bus structure for a big CMS - but that falls back to the age old argument with single task controllers. Having built some large components recently I'm seriously unconvinced by single task controllers. I'd have so many files it would be almost unmaintainable. Of course if you are building an API then single task controllers are almost essential. But I honestly think given my experience over the last 6 months that single task controllers with command buses are not the right way for the CMS to go
Finally niels your tweet was just that you were going to include it in Joomla 4. This is just a proposal it is NOT guaranteed in any way to be in J4.
Kind Regards,
George
Chris Davenport
Jan 19, 2016, 4:30:17 AM1/19/16
to Joomla! CMS Development
Hi George,
On 18 January 2016 at 22:35, George Wilson <georgeja...@googlemail.com> wrote:
Please work on the way you are using the DIC in your app. This is like a service locator (http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/) rather than a DIC.
Thanks for the link. Michael has also made some very helpful comments. I'm still getting my head around the "right" way to use a container, but I think I'm beginning to see the light. Actually, I'm not sure using a container is the best way to go about this anyway. It needs to be easy to inject custom middleware into the command bus stack, but this is only possible right now by replacing the entire provider. There needs to be a better way of doing that.
Personally I also hate empty interfaces (https://github.com/chrisdavenport/service/blob/master/src/Command.php , https://github.com/chrisdavenport/service/blob/master/src/Event.php etc.)
Most of the empty interfaces started out with at least one method signature in them, but later versions of PHP seem to complain about anything that breaks LSP, so I had to drop them from the interface. I like to have good type hinting though. I suppose where there is currently an empty interface I should use that name for the abstract base class instead. Other suggestions welcome.
Honestly I'm not convinced by the command bus structure for a big CMS - but that falls back to the age old argument with single task controllers. Having built some large components recently I'm seriously unconvinced by single task controllers. I'd have so many files it would be almost unmaintainable. Of course if you are building an API then single task controllers are almost essential.
I don't think this has anything to do with single task controllers. Even with a command bus you are free to use either single or multi-task controllers. It makes no difference. I'm not sure why you think the number of files has anything to do with the maintainability of the code either. I suspect the problem you (don't really) describe is "how do I find the right piece of code in all these files" problem. But that really comes down to consistent, logical organisation and good naming.
The code needs to match the developer's expectation of where it should be found. The "multi-task" approach is to lump lots of methods into one class/file and rely on good naming of tasks/methods to find the code. The "single-task" approach is to rely on good class/file names to give the clue about what lies within. Both approaches are equally valid. The command bus does not enforce one approach or the other. I've chosen to split command handlers into separate files because I prefer that approach (and that's the approach that most other software projects use), but you can easily configure the command bus to use command handlers which are methods inside one big class if you prefer. There are lots of options. You can even use closures. Look at https://tactician.thephpleague.com/tweaking-tactician/ to see the choices available.
But I honestly think given my experience over the last 6 months that single task controllers with command buses are not the right way for the CMS to go
My experience over the last 6 months is that it is precisely in those larger projects that the service layer/command bus comes into its own. It allows a much clearer separation of concerns than the traditional approach and that makes it easier to debug. Combined with the DDD approach it also makes it easier to add new functionality without breaking existing code.
Chris.
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
Chris Davenport
Jan 24, 2016, 12:27:34 PM1/24/16
to Joomla! CMS Development
After playing around with trying to configure the command bus using the container I eventually decided it was just so much simpler to use a builder class instead. So, there is now a relatively simple builder class which provides a default configuration and an API that makes it easy for advanced users to override the default and configure their own command bus. The command bus itself is now passed into command handlers and domain event listeners, rather than a container.
I've also dropped all the empty interfaces in favour of suitably renamed abstract base classes. Plus a whole bunch of other clean-ups.Thanks for the feedback.
Chris Davenport
Jan 24, 2016, 12:41:18 PM1/24/16
to Joomla! CMS Development
I've also now updated the contacts component PR that demonstrates the use of the service layer.
https://github.com/joomla/joomla-cms/pull/8747
Chris.https://github.com/joomla/joomla-cms/pull/8747
Abu Huraira Bin Aman
Apr 8, 2016, 11:21:49 AM4/8/16
to Joomla! CMS Development
Hi
Today i tried to install it through composer, but tactician installation fails.
error:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- league/tactician v0.6.1 requires php >=5.5 -> your PHP version (5.5.9-1ubuntu4.14) overriden by "config.platform.php" version (5.3.10) does not satisfy that requirement.
- chrisdavenport/service dev-master requires league/tactician ^0.6.1 -> satisfiable by league/tactician[v0.6.1].
- Installation request for chrisdavenport/service dev-master -> satisfiable by chrisdavenport/service[dev-master].
And i'm not clear how to use it too.
this service layer can be used for api? but i wanna bypass all the events through entire joomla.
only few events will be available through it?
thanks
Chris Davenport
Apr 8, 2016, 7:29:00 PM4/8/16
to Joomla! CMS Development
Hmm. Yes, you're right about the composer error. Looks like I'm running the exact same version of Ubuntu as you and I get the exact same error so I can no longer install the package myself. It used to work, so something has changed, but I'm not sure what. I've tried a few things, but I don't know enough about composer to know how to fix it. Looks like composer is not parsing the PHP version number correctly. Possibly a bug in composer? It seems to be a widely reported issue, but none of the suggested solutions I've found so far work for me.
Anyway, to try to answer your other questions...There's a great introduction to the idea of a service layer and domain events here: https://www.youtube.com/watch?v=ajhqScWECMo
Chris.
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
Michael Babker
Apr 8, 2016, 8:24:32 PM4/8/16
to joomla-...@googlegroups.com
The config.platform.php key in Composer's schema instructs it to check PHP as if you're running the specified version in that value versus your actual PHP version. So the error is actually fully right (a package requires PHP 5.5.9+ but Composer was told to run as PHP 5.3.10.
--
- Michael
This key is specified on the CMS' composer.json too so that nobody accidentally updates a dependency to a non-compatible version. We also use that key in the issue tracker's composer.json to map the PHP version that gets checked to the version currently deployed on the server.
--
- Michael
Please pardon any errors, this message was sent from my iPhone.
Chris Davenport
Apr 9, 2016, 3:48:05 AM4/9/16
to Joomla! CMS Development
Thanks Michael. Okay, so I managed to get it to install by doing this:
* Remove the config.platform.php entry from composer.json
* rm composer.lock
* composer require chrisdavenport/service:dev-master
* composer require chrisdavenport/service:dev-master
I haven't gone any further though, so I don't know whether that has broken something else.
George Wilson
Apr 9, 2016, 10:25:22 AM4/9/16
to Joomla! CMS Development
The error is intentional and the config.platform.php is designed to "enforce" this error.
The tactician package has a minimum requirement of PHP 5.5 - this is incompatible with the 5.3 minimum that we require - hence composer currently throws an error.
That's down to you to find a solution for :)
Kind Regards,
George
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
--Chris Davenport
Joomla Production Leadership Team
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
--
- MichaelPlease pardon any errors, this message was sent from my iPhone.
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
Sergio Manzi
Apr 9, 2016, 10:34:15 AM4/9/16
to joomla-...@googlegroups.com
methink Joomla should change its policy about maintaining minimum
requirements when bumping minor releases.
Still stuck with maintaining PHP 5.3 compatibility? OMG...
Still stuck with maintaining PHP 5.3 compatibility? OMG...
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Leo Lammerink
Apr 9, 2016, 10:58:02 AM4/9/16
to joomla-...@googlegroups.com
Sergio,
look at the forums and you will be amazed how many hosting providers still run that version. At present we cannot say farewell yet regretfully
look at the forums and you will be amazed how many hosting providers still run that version. At present we cannot say farewell yet regretfully
George Wilson
Apr 9, 2016, 11:31:13 AM4/9/16
to Joomla! CMS Development
5.3 is about 14% of our usage https://developer.joomla.org/about/stats.html (3.5 features do things - yay :P)
Kind Regards,
George
Sergio Manzi
Apr 9, 2016, 12:24:53 PM4/9/16
to joomla-...@googlegroups.com
Yeap, but: how many new installation you loose (for
lack of innovation in Joomla) because of the "Customer
retention" policy?
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Sergio Manzi
Apr 9, 2016, 12:43:24 PM4/9/16
to joomla-...@googlegroups.com
Please compare:
The "3 big ones":
The "3 big ones":
http://w3techs.com/technologies/details/cm-wordpress/all/allThe small ones in my radar:
http://w3techs.com/technologies/details/cm-joomla/all/all
http://w3techs.com/technologies/details/cm-drupal/all/all
http://w3techs.com/technologies/details/cm-grav/all/all
http://w3techs.com/technologies/details/cm-octobercms/all/all
Michael Babker
Apr 9, 2016, 1:39:33 PM4/9/16
to joomla-...@googlegroups.com
My two cents, 4.0 can drop 5.3 and 5.4 support easily. 2014 LTS releases standardized on PHP 5.5.9 or later for the most part and most PHP projects are locking to that if not a newer version.
Dropping it in a minor is going to be more of a PITA than the JMail fixes. Remember the uproar because Joomla stopped supporting Linux LTS' PHP 5.3.3 builds?
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
--
Chris Davenport
Joomla Production Leadership Team
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
--
- MichaelPlease pardon any errors, this message was sent from my iPhone.
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
--
Chris Davenport
Joomla Production Leadership Team
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
George Wilson
Apr 9, 2016, 2:03:47 PM4/9/16
to Joomla! CMS Development
Ubuntu 16.04 ships with PHP 7. A boy can dream..... (source: https://www.symfony.fi/entry/php-7-included-in-ubuntu-16-04-lts-xenial-xerus )
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
--
Chris Davenport
Joomla Production Leadership Team
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
--
- MichaelPlease pardon any errors, this message was sent from my iPhone.
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
--
Chris Davenport
Joomla Production Leadership Team
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
Sergio Manzi
Apr 9, 2016, 2:21:39 PM4/9/16
to joomla-...@googlegroups.com
Dreams apart, we probably can't change the rule of the game
while still playing, but my personal opinion is that starting with
4.0 we should:
- Bind the "major release bump" only to changes in the API
- Keep the freedom to bump requirements @minor releases bump
- Be reasonable (apply the concept of being "good family fathers") and bump requirements only when technologically needed and after an accurate market analysis of what hosting providers do actually offers
Applying the above criteria as of today I wouldn't see a drama in
raising PHP requirement to 5.5.something (basing this
on a document Michael posted earlier:
http://phpversions.info/shared-hosting/)
If there is a fringe number of hosting providers not providing
5.5.x, their customer should be taught of the reasons why it would
be in their best interest to migrate to a different host.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Michael Babker
Apr 9, 2016, 2:31:28 PM4/9/16
to joomla-...@googlegroups.com
See that's the thing. Joomla really hasn't needed a PHP 5.4+ feature. We've adopted some made available in polyfills because those features and the polyfills were better than what we had before, otherwise there hasn't been a strong argument for dropping 5.3 support other than it isn't supported anymore. And I've really tried looking for things that are holding Joomla back because of PHP 5.3 support.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
--
Chris Davenport
Joomla Production Leadership Team
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
--
- MichaelPlease pardon any errors, this message was sent from my iPhone.
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.
--
Chris Davenport
Joomla Production Leadership Team
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
Sergio Manzi
Apr 9, 2016, 2:41:00 PM4/9/16
to joomla-...@googlegroups.com
That's why I said "...and bump requirements only when
technologically needed"
There isn't PHP only, thus: MySQL can be part of the equations too, and libraries we depend on, now and in the future.
There isn't PHP only, thus: MySQL can be part of the equations too, and libraries we depend on, now and in the future.
Sergio Manzi
Apr 9, 2016, 2:44:06 PM4/9/16
to joomla-...@googlegroups.com
"though" I meant, not "thus"!! :-)
Michael Babker
Apr 9, 2016, 3:11:11 PM4/9/16
to joomla-...@googlegroups.com
Even in those there's nothing Joomla needs that can't be conditionally handled (i.e. MySQL utf8mb4). PHP 5.3 was arguably a need because of the number of static APIs still and being able to use late static bindings to improve extensibility of them. Maybe in 5 years the argument will be different but personally I'd say right now most aren't arguing for new minimums (Joomla nor greater PHP) for language features with the exception of PHP 7's scalar type hints, but rather taking the stance of not supporting unsupported platforms.
Sergio Manzi
Apr 9, 2016, 3:35:42 PM4/9/16
to joomla-...@googlegroups.com
OK, you win! :-)
But wasn't this thread started because the service layer proposed by Chris for incorporation into Joomla (an innovation...) has a requirement of PHP 5.5 min?
But wasn't this thread started because the service layer proposed by Chris for incorporation into Joomla (an innovation...) has a requirement of PHP 5.5 min?
Chris Davenport
Apr 9, 2016, 6:11:55 PM4/9/16
to Joomla! CMS Development
The proposed service layer is an optional library that will be
available to third-party and custom extension developers. I'm not
proposing to refactor any of the core components to use it at this
stage. Consequently it would be a bit like the DI package which is
already included in the distribution and includes traits that can only
be used in PHP 5.4+ code.
If the decision is that we can't include optional libraries that have minimum requirements that are greater than the CMS's, then there are several ways to move forward:
* Fork and downgrade Tactician to work on PHP 5.3.10+.
* Find a different command bus implementation that will work on PHP 5.3.10+.
* Rewrite it as a library that can be installed using the CMS extension installer, checking for PHP 5.5+ in preflight.
I don't have a strong preference, although the last option is probably the least amount of work. They all have downsides.
Alternatively, it can just be flagged for possible inclusion in Joomla 4.
Michael Babker
Apr 9, 2016, 7:03:41 PM4/9/16
to joomla-...@googlegroups.com
Last derailing (from me)
My main point is that there are a lot of nifty things in PHP 5.4+ that might strengthen the code base but there isn't a single feature we haven't already implemented with a polyfill for older version support that will make Joomla 37x more amazing by implementing them. The last major language change that Joomla needed was late static bindings. Traits in 5.4 might help give reusable behaviors across class chains and a couple 5.4 features might help make some code less verbose. 5.6's variadic functions might make some method signatures less magic and has a __debugInfo magic method (which can be implemented without bumping the minimum as it's just a method in a class, the feature just isn't available in 5.5 or older). Otherwise, there honestly is not a lot of technical reason for a PHP bump, that's my honest assessment after going over a large chunk of Joomla's code. Bumping does let us pull dependencies which aren't supporting our minimums or take a stance on how many EOL PHP versions we'll support.
As for other platform minimums, given Joomla's heavy use of JSON data, MySQL 5.7's JSON field type is interesting. And in 5 years when enough hosts make it available we can toy with it.
Sergio Manzi
Apr 9, 2016, 7:38:40 PM4/9/16
to joomla-...@googlegroups.com
OK, Michael, I trust you, and I really mean it. I swear it on my
dearest things. You have so much more experience in PHP (heck,
you can give me PHP 101!) and software development that it
would be foolish for me not trusting you on that.
See me just as an observer that has a lot less competence than you have, but that (not to his merit, but just for mere age reasons) has been thru a multitude of projects and has refined a sixth sense for what can represent critical decisions. To me what I proposed (i.e. levy the "verboten" on bumping minimum requirements for minor releases) is just that: a degree of freedom that I strongly feel could become handy in the future, for everybody.
I hope you understand my position that has absolutely nothing to do with your totally valid technical points.
Friendly,
Sergio
See me just as an observer that has a lot less competence than you have, but that (not to his merit, but just for mere age reasons) has been thru a multitude of projects and has refined a sixth sense for what can represent critical decisions. To me what I proposed (i.e. levy the "verboten" on bumping minimum requirements for minor releases) is just that: a degree of freedom that I strongly feel could become handy in the future, for everybody.
I hope you understand my position that has absolutely nothing to do with your totally valid technical points.
Friendly,
Sergio
Reply all
Reply to author
Forward
0 new messages