compared with
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (16)

View Page History

* Define what parts of {{Zend\Tool\*}} ecosystem is reusable in context of ZF2 (what have been already refactored, what need to be removed)
* Understand the need or the lack of support for code generating capabilities previously available in via {{Zend\Tool\Project}} (but not limited to them)

h2. Requirements

* have way more simple {{Zend\Tool}} component
* have {{ZendToolProviders}} ZF2 module. It will contain set of default providers (providers found in {{Zend\Tool\Framework\System\Provider}}). {{Zend\Tool\Project\Provider}}).
* providers found in found in {{Zend\Tool\Framework\System\Provider}}, {{Zend\Tool\Framework\System\Provider}} should remain w/i framework's core, so that they are available w/o {{ZentToolProviders}} module installation.
* {{Zend\Tool\Project\Provider}} will be moved into {{ZendToolProviders}} module sub-module.
* {{zf2.php}} will be a rewrite of {{zf.php}} utilizing {{Zend\Console}}

h3. Zend\Tool Component

Primary responsibility will be to aid 3rd party modules having console routes defined.
Primary responsibility will be to provide utility functionality to any console-enabled modules.

While {{Zend\Tool\Framework}} was full-fledged framework, {{Zend\Tool}} in ZF2 will be a more light-weight solution delegating all the leg-work to 3rd party modules (with default providers being part of [ZendTool|] module).
While {{Zend\Tool\Framework}} was full-fledged framework, {{Zend\Tool}} in ZF2 will be a more light-weight solution delegating all of the leg-work to providers modules.

A good example of what might go into {{Zend\Tool}} component are marker interfaces, like {{Provider}} and {{Pretandable}} (aka dry-run) allowing dry-run). This will allow to have framework -defined standards for concrete providers.

h3. ZendToolProviders module

* We may pick another name, I am not particularly good at naming
* Will contain all basic code generation functionality, including:
** modules
** unit tests
** form
** style and script assets (this (these can go into separate assetic module of course)
* It is probably good idea to have better integration for ORM entities (so that forms might be generated from them). This is a serious question though, requiring serious consideration.
* Will play nicely with 3rd party console-enabled modules
h2. Functional Segmentation

Very important issue is functionality segmentation: separation by responsibility: for ex, Doctrine2 migrations or schema handling module may (and probably should) define its own providers.
The aim is to standardize the way providers are created, and provide single point of access via which those providers will be used: that's via {{zf2}} script.

h2. zf2.php and module installation

Good stress test for the whole idea of having descrete separate modules for different provider sets of providers is module [installation and distribution|].

It is expected that {{zf2.php}} is capable of installing/updating modules, so here is the question to anyone who have spent some brain-power analyzing best ways to install modules:
Will it be feasible to create some {{ZendToolModuleManager}} module, which will be exposed via proposed {{zf2.php}} tool?

Will it be too much to ask end-user to install some standard modules in addition to core libs, to utilize framework in a more pleasant way?

h2. Roadmap

* After gathering some input to confirm that the whole idea is sane, first step will be to implement {{zf2.php}} tool
* Once done, {{Zend\Tool\Project\Provider}} need to be migrated to [ZendToolProviders|] repo
* Some docs on how to expose zf2 console-enabled controllers, so that any other modules may be updated:
h2. Alternatives

When considering whether we need support for scaffolding/code generation it is worth looking at how others have tacklesd the same problem:

- RoR has amazingly complete CLI tools (including code generators), Symfony2 follows the suit.