RFC: Service Components (Moving Zend\Service out of the core)

[Mike Willbanks]

Hello Everyone,

With the help of Gary (Spabby) to get this started while I was out;
we've been able to provide a draft of the Service Components RFC.
Please read through the RFC and provide comments and feedback; ideally
we will be able to get all feedback and start to come to a good
consensus by the end of this week.  Which means the RFC could be
updated and voted on in the IRC meeting next week (assuming feedback
and general consensus is able to be formed within this time period).

The RFC can be found at
http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Service+Components

Regards,

Mike Willbanks (mwillbanks)

[Jurian Sluiman-3]

2012/3/21 Mike Willbanks <[hidden email]>

Hello Everyone,

With the help of Gary (Spabby) to get this started while I was out;
we've been able to provide a draft of the Service Components RFC.
Please read through the RFC and provide comments and feedback; ideally
we will be able to get all feedback and start to come to a good
consensus by the end of this week.  Which means the RFC could be
updated and voted on in the IRC meeting next week (assuming feedback
and general consensus is able to be formed within this time period).

The RFC can be found at
http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Service+Components

Regards,

Mike Willbanks (mwillbanks)

Hi Mike,

Thanks for the great work. I think this was really needed to get all Zend\Service\* components on the same line with equal quality. The only remark I would like to make is that of components vs. modules. No, not the same discussion as some months ago, but I would argue all Zend\Service* classes would typically be a module (as I and some others have argued before).

A component is "just" some piece of library code, without a further defined (directory) structure. A module _has_ a specific (though only recommended) structure where configuration, documentation and tests are incorporated. A module is by far the most standalone, all-in-one package, as it provides its own autoloading (by using spl_autoload_register() or the classmap autoloader). To keep it structured, things don't look too good for a component in this picture.

Next, the module is much more easier to use, as you simply clone such git repository to a location known by the module manager and enable it in the configuration. A component has (yet?) not a defined location in a Zend Application. There is no autoloading mechanism provided too, so you have to set up the StandardAutoloader yourself and/or generate a classmap. Some days ago the new console tooling has been presented, also here are the wins for modules I think. I expect on a short term a recommended structure to put tests in your module, making it possible to run unit tests and integration tests for the complete application. Here again, nothing defined for components....

....yet. Ok, you can extend your RFC to make rules for everything we did for modules already. Why, do we need that?

A third point is configuration: again for modules, the manager can load configuration files and merge those. This is user friendly as modules can provide their own DI definitions. No developer need to write the inter-component DI relations, but only inject a top level object in his (her) own application and s/he is ready to go. The same holds for service specific credentials (api keys, usernames, passwords): most modules in need for such credentials (examples: DoctrineModule, EdpGithub, SlmMail) have a simple place to put those in.

As last, there is in my opinion also nothing _against_ modules. They have a minimal overhead, are extremely flexible and might provide anything. So if others don't agree: what are the benefits for a component?

PS. I know we are heading into a grey area here, as before (zf1) we had no such module/component separation and at this time (with zf2) we have not accessed this area-in-between yet. There are of course always service components which should stay components, with Zend\Cloud the best example.

-- 

Jurian Sluiman

[weierophinney]

-- Jurian Sluiman <[hidden email]> wrote
(on Wednesday, 21 March 2012, 06:43 PM +0100):

> 2012/3/21 Mike Willbanks <[hidden email]>
>     With the help of Gary (Spabby) to get this started while I was out;
>     we've been able to provide a draft of the Service Components RFC.
>     Please read through the RFC and provide comments and feedback; ideally
>     we will be able to get all feedback and start to come to a good
>     consensus by the end of this week.  Which means the RFC could be
>     updated and voted on in the IRC meeting next week (assuming feedback
>     and general consensus is able to be formed within this time period).
>
>     The RFC can be found at
>     http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Service+Components
>
>     Regards,
>
>     Mike Willbanks (mwillbanks)
>
> Thanks for the great work. I think this was really needed to get all Zend\
> Service\* components on the same line with equal quality. The only remark I
> would like to make is that of components vs. modules. No, not the same
> discussion as some months ago, but I would argue all Zend\Service* classes
> would typically be a module (as I and some others have argued before).
>
> A component is "just" some piece of library code, without a further defined
> (directory) structure. A module _has_ a specific (though only recommended)
> structure where configuration, documentation and tests are incorporated. A
> module is by far the most standalone, all-in-one package, as it provides its
> own autoloading (by using spl_autoload_register() or the classmap autoloader).
> To keep it structured, things don't look too good for a component in this
> picture.

I have to disagree here. What you describe as a "module" in the above is
exactly how ZF2 components are delivered via our Pyrus channel at
http://packages.zendframework.com/ (or at least the intention). And if
you look at traditional Pear packages, most contain tests, docs, often
even autoloaders (PHPUnit contains one, for instance).

A "Module" in ZF2 parlance is typically code you want to somehow tie
into an MVC application. This may or may not be the case with service
classes, as you may be using them from console scripts, or from non-ZF2
applications.

Basically, your arguments about the _structure_ of a module vs a
component to me are invalid -- they can each have the same basic
structure.

> Next, the module is much more easier to use, as you simply clone such git
> repository to a location known by the module manager and enable it in the
> configuration. A component has (yet?) not a defined location in a Zend
> Application.

"vendor/" is for 3rd party code -- be it a library, a component, or a
module. In my apps, I have both ZF2 and modules in vendor/ currently. As
such, yes, we do have a location.

> There is no autoloading mechanism provided too, so you have to set
> up the StandardAutoloader yourself and/or generate a classmap.

I'd argue we'd include the following in these, regardless of how we end
up packaging them:

 * autoload_classmap.php (the classmap for use with ClassMapAutoloader)
 * autoload_function.php (a callback for registering with
   spl_autoload_register)
 * autoload_register.php (register the above function with
   spl_autoload_register)

Alternately, we can have pyrus generate an autoloader automatically
(which we do with the other ZF2 components); this allows the following:

    require 'path/to/Component.phar';
    $service = new Component();

which is nice and simple.

> Some days ago the new console tooling has been presented, also here
> are the wins for modules I think. I expect on a short term a
> recommended structure to put tests in your module, making it possible
> to run unit tests and integration tests for the complete application.

Again, for components, you'd have a test/ directory, just like modules.
The difference is that you likely don't need any application-awareness
-- the component should be basically standalone, other than some
dependencies (which you can provide paths to in the test/ directory via
local configuration).

My point is this: I think you're reading too much into what a module
delivers over what a component delivers. The structure of most component
code I've seen is very similar to what we do in our modules -- they
simply don't include the Module.php, and usually only include
configuration as documentation.

<snip>

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

[Mike Willbanks]

Hello,

>> A component is "just" some piece of library code, without a further defined
>> (directory) structure. A module _has_ a specific (though only recommended)
>> structure where configuration, documentation and tests are incorporated. A
>> module is by far the most standalone, all-in-one package, as it provides its
>> own autoloading (by using spl_autoload_register() or the classmap autoloader).
>> To keep it structured, things don't look too good for a component in this
>> picture.
>
> I have to disagree here. What you describe as a "module" in the above is
> exactly how ZF2 components are delivered via our Pyrus channel at
> http://packages.zendframework.com/ (or at least the intention). And if
> you look at traditional Pear packages, most contain tests, docs, often
> even autoloaders (PHPUnit contains one, for instance).
>
> A "Module" in ZF2 parlance is typically code you want to somehow tie
> into an MVC application. This may or may not be the case with service
> classes, as you may be using them from console scripts, or from non-ZF2
> applications.

I want to ensure that you mean more around the controller and view
side of the coin by providing an actual implementation vs. providing
convenience methods for Mvc like helpers and the like as helpers will
likely be in large a big portion of components (view helpers,
controller plugins, controller helpers, etc).  So that we are all on
the same page; I can document this in the wiki later.

> Basically, your arguments about the _structure_ of a module vs a
> component to me are invalid -- they can each have the same basic
> structure.
>
>> Next, the module is much more easier to use, as you simply clone such git
>> repository to a location known by the module manager and enable it in the
>> configuration. A component has (yet?) not a defined location in a Zend
>> Application.
>
> "vendor/" is for 3rd party code -- be it a library, a component, or a
> module. In my apps, I have both ZF2 and modules in vendor/ currently. As
> such, yes, we do have a location.
>
>> There is no autoloading mechanism provided too, so you have to set
>> up the StandardAutoloader yourself and/or generate a classmap.
>
> I'd argue we'd include the following in these, regardless of how we end
> up packaging them:
>
>  * autoload_classmap.php (the classmap for use with ClassMapAutoloader)
>  * autoload_function.php (a callback for registering with
>   spl_autoload_register)
>  * autoload_register.php (register the above function with
>   spl_autoload_register)
>
> Alternately, we can have pyrus generate an autoloader automatically
> (which we do with the other ZF2 components); this allows the following:
>
>    require 'path/to/Component.phar';
>    $service = new Component();
>
> which is nice and simple.

I agree here completely.

>> Some days ago the new console tooling has been presented, also here
>> are the wins for modules I think. I expect on a short term a
>> recommended structure to put tests in your module, making it possible
>> to run unit tests and integration tests for the complete application.
>
> Again, for components, you'd have a test/ directory, just like modules.
> The difference is that you likely don't need any application-awareness
> -- the component should be basically standalone, other than some
> dependencies (which you can provide paths to in the test/ directory via
> local configuration).
>
> My point is this: I think you're reading too much into what a module
> delivers over what a component delivers. The structure of most component
> code I've seen is very similar to what we do in our modules -- they
> simply don't include the Module.php, and usually only include
> configuration as documentation.

I think we do need to define this at a good level either through this
proposal or a separate initiative to be able to explain the
differences between the two or at a minimum what is expected out of
the two (components / modules).  This might be able to create more of
a clear picture of how we organize and talk about things.

Regards,

Mike