Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Tool_Framework Component Proposal

Proposed Component Name Zend_Tool_Framework
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Tool_Framework
Proposers Ralph Schindler
Zend Liaison TBD
Revision 1.0 - 2 June 2008: Initial Draft. (wiki revision: 8)

Table of Contents

1. Overview

Zend_Tool_Framework is a component that is a generalize RPC-style framework for building a system that is capable of exposing, dispatching, and responding to requests that facilitate anything in the realm of "progmatic tooling".

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will provide a Command Line Interface endpoint.
  • This component will be extensible for additional endpoint interfaces: RPC, Code based, or perhaps other IDE's
  • This component will not provide any project management utilities.
  • This component will not provide any means of templating or code generation

4. Dependencies on Other Framework Components

  • Zend_Console_Getopt
  • PHP's Reflection
  • Zend_Loader
  • Zend_Version

5. Theory of Operation

Goals

Zend_Tool_Framework is a framework that provides:

  • common interfaces, abstracts that allow will allow developers (through the most minimal of efforts) to create functionality and capabilities that are dispatchable by "tooling clients" (2).
  • Implementation of "endpoints" (5) to be used to connect "tooling clients" to the Zend_Tool_Framework, the primary endpoint implementation being that of the "Command Line Interface Endpoint" (6)
  • Implement interfaces that will identify classes as "Provider" or "Manifest" classes that can be utilized by the tooling system.
  • Implement a standard set of "system/help providers" (8) that allow the system to report what the full capabilities of the system are as well as provide useful feedback. This might also be known as a "Help System".

In a more general sense, Zend_Tool_Framework might be useful in creating a system that can expose common functionalities such as the creation of files, the creation of project scaffolds, building of indexes, ... the list goes on. Central to all of the tasks of tooling is a resounding theme:

"Dont work harder, work smarter."

The subsystems that make up Zend_Tool_Framework

Zend_Tool_Framework_Provider

Zend_Tool_Framework_Provider_Interface

Zend_Tool_Framework_Provider represents the functional or "capability" aspect of the Zend_Tool_Framework framework. Fundamentally, Zend_Tool_Framework_Provider will provide the interfaces necessary to produce "providers", or bits of tooling functionality that can be called and used inside the Zend_Tool_Framework toolchain. The simplistic nature of implementing this "provider interface" allows the developer a "one-stop-shop" of adding functionality/capabilities to the Zend_Tool_Framework.

The provider interface is an empty interface and enforces no methods (this is the Marker Interface pattern):

For example, if a developer wants to add the capability of showing the version of a datafile that his 3rd party component is working from, there is only one class the developer would need to implement. Assuming the components is called Some3rdParty_Component, he would create a class/file named Some3rdParty_Component_MyZfTool (MyZfTool.php). This class would implement Zend_Tool_Framework_Provider_Interface and the body of this file would only have to look like the following:

Given that code above, and assuming the developer wishes to access this functionality through the Command Line Tooling Client, the call would look like this:

#zf show my-version
Version number is: 4.0

Zend_Tool_Framework_Provider_Registry

The primary objective of the Provider Registry is to take providers into the registry and process them into dispatchable methods. Provides will generally be introduced into the registry by means of a Loader (more on this concept in a later section of this proposal).

The provider registry's purpose is two fold. First, the registry will take complete provider marked objects (marked by Zend_Tool_Framework_Provider_Interface), then break them down into a signature object (Zend_Tool_Framework_Provider_Signature) that is capable of describing (in more finite terms) what actionable methods each provider is capable of dispatching.

Providers are similar in nature to action controllers in that each public method defined within a provider will become an actionable method. Generally, methods should be a verb. For example, if we had a "Version" provider. We might have a show() method. This allows us to issue the command "SHOW the VERSION".

Providers are capable of allowing the developer to organize a provider classes methods into groups by means of defining "Provider Specialties". To define specialties, all a provider must have is a protected/private method named $_specialties. The contents of this property should be an array of names of the specialties inside the provider. For example, lets say you only wanted the Version provider to return the major version number part of the version string. To accomplish this, we would create a protected $_specialties = array('MajorPart'); property, and also create a method named showMajorPart() {}. This will then create an additional signature that can be dispatched by an endpoint. This dispatchable method is equivalent to the following command: "SHOW the MAJOR-PART of the VERSION".

Specialties are implemented so that providers do not run out of naming room inside their action/method namespace. This allows you to dispatch (with the same action), a number of different specialties of a provider.

Zend_Tool_Framework_Manifest

In short, the Manifest shall contain specific or arbitrary metadata that is useful to any provider or endpoint, as well as be responsible for loading any additional providers into the provider registry.

To introduce metadata into the registry, all one must do is implement the empty Zend_Tool_Framework_Manifest_Interface, and provide a getMetadatas() method which shall return an array of objects that implement Zend_Tool_Framework_Manifest_Metadata.

Metadata objects are loaded (by a loader defined below) into the Manfiest Registry (Zend_Tool_Framework_Manifest_Registry). Manifests will be processed after all Providers have been found a loaded into the provider registry. This shall allow Manifests to created Metadata objects based on what is currently inside the Provider Registry.

Zend_Tool_Framework_Loader

The purpose of the Registry Loader is to find Providers and Manifest files that implement either Zend_Tool_Framework_Provider_Interface or Zend_Tool_Framework_Manifest_Interface. Once these files are found by a loader, providers are loaded into the Provider Registry and manifest metadata is loaded into the Manifest Registry.

Zend_Tool_Framework_Loader_IncludePathLoader

By default, the Tooling framework will use an include path based loader to find files that might include Providers or Manifest Metadata objects. Zend_Tool_Framework_Loader_IncludePathLoader, without any other options, will search for files inside the include path that end in Mainfest.php, Tool.php or Provider.php. Once found, they will be tested (by the load() method of the Zend_Tool_Framework_Loader_Abstract) to determine if they implement any of the supported interfaces. If they do, an instance of the found class is instantiated, and it is appended to the proper registry.

Zend_Tool_Framework_Endpoint

Zend_Tool_Framework_Endpoint is the externally exposed interface that consumers are expected interact with the Zend_Tool_Framework system through. The first endpoint executed shall be a command line interface. The Endpoint shall implement a static main() method such that will setup a default instance of the endpoint being used. The endpoint will be responsible for taking any environment or user supplied information, parsing it, and dispatching an actionable method on a provider. The output from the provider will then be provided to the endpoint implementation to send back to the user in a format that makes sense to the endpoint's implementation.

Zend_Tool_Framework_Provider's built in providers

These providers will be able to allow the system to reflect back to the user all of the capabilities and providers that are loaded within the tooling system.

  • Version

Definitions and Terms

(1) Zend_Tool_Framework - The framework which exposes tooling capabilities.

(2) Tooling Client - A developer tool that connects to and consumes "Zend_Tool_Framework".

(3) Command Line Tool / Command Line Interface / zf.php - The "tooling client" for the command line.

(4) Zend Studio - An IDE based "tooling client", connects via the RPC "Zend_Tool_Framework_Endpoint"

(5) Endpoint - The subsystem of "Zend Tool" that exposes an interface such that "tooling clients" can connect, query and execute commands.

(6) Cli Endpoint - An endpoint implementation responsible for exposing "Zend Tool RPC" via the "command line interface".

(7) Rpci Endpoint - An endpoint implementation responsible for exposing "Zend Tool RPC" via the "remote procedure call interface".

(8) Provider - A subsystem and a collection of built-in functionality that the "Zend Tool" system exports.

(9) ZFProject Provider - A set of providers specifically for creating and maintaining Zend Framework based projects.

(10) Manifest - A subsystem for defining, organizing, and disseminating "provider" requirement data.

6. Milestones / Tasks

  • Milestone 1: design notes will be published here
  • Milestone 2: Working prototype checked into the incubator supporting use cases #1, #2, ...
  • Milestone 3: Working prototype checked into the incubator supporting use cases #3 and #4.
  • Milestone 4: Unit tests exist, work, and are checked into SVN.
  • Milestone 5: Initial documentation exists.

If a milestone is already done, begin the description with "[DONE]", like this:

  • Milestone #: [DONE] Unit tests ...

7. Class Index

Zend_Tool_Framework_Endpoint
Zend_Tool_Framework_Endpoint_Abstract
Zend_Tool_Framework_Endpoint_Dispatcher
Zend_Tool_Framework_Endpoint_Exception
Zend_Tool_Framework_Endpoint_Request
Zend_Tool_Framework_Endpoint_Response
Zend_Tool_Framework_Loader
Zend_Tool_Framework_Loader_Abstract
Zend_Tool_Framework_Loader_Chain
Zend_Tool_Framework_Loader_IncludePathLoader
Zend_Tool_Framework_Loader_IncludePathLoader_RecursiveFilterIterator
Zend_Tool_Framework_Loader_IncludePathLoader
Zend_Tool_Framework_Manifest
Zend_Tool_Framework_Manifest_ActionMetadata
Zend_Tool_Framework_Manifest_Interface
Zend_Tool_Framework_Manifest_Metadata
Zend_Tool_Framework_Manifest_ProviderMetadata
Zend_Tool_Framework_Manifest_Registry
Zend_Tool_Framework_Provider
Zend_Tool_Framework_Provider_Action
Zend_Tool_Framework_Provider_Interface
Zend_Tool_Framework_Provider_Registry
Zend_Tool_Framework_Provider_Signature
Zend_Tool_Framework_System
Zend_Tool_Framework_System_Action
Zend_Tool_Framework_System_Action_Create
Zend_Tool_Framework_System_Action_Delete
Zend_Tool_Framework_System_Manifest
Zend_Tool_Framework_System_Provider
Zend_Tool_Framework_System_Provider_Providers
Zend_Tool_Framework_System_ProviderVersion

8. Use Cases

UC-01

9. Class Skeletons

]]></ac:plain-text-body></ac:macro>

]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jun 04, 2008

    <p>I want to propose few enhancements that will ease the work with the build tool:</p>

    <p>1. For each command we should provide a list of "mandatory" and "optional" options <br />
    2. Provide a command that syncs between the repository and the current project, basing it on a given repository.</p>

  2. Jun 04, 2008

    <p>Great suggestions Roy.</p>

    <p>As far as # 1, that will be part of the help and exception system I need to build in yet. That definitely needs to be implemented into Zend_Tool_Rpc</p>

    <p>As for #2, we discussed that and that too is a good idea. Although, that applies more to the Zend_TOol_Project proposal than the Zend_Tool_Rpc proposal. But basically, it might be implemented as a "scan" or "sync" project tool.</p>

    <p>-ralph</p>

    1. Jun 04, 2008

      <p>Thanks you Ralph for a fabulous component, I am sure the ZF community will be happy to adopt it! (and reuse it)</p>

  3. Jun 23, 2008

    <p>Specifics:</p>

    <ul>
    <li>Do providers just provide help, as implied in the Goals section, or do they actually expose interfaces to the functionality in question? I see the answer in the definitions, but it might help to clarify here.</li>
    </ul>

    <ul>
    <li>Zend_Tool_Rpc_Provider_Interface implements the 'Marker Interface' pattern.</li>
    </ul>

    <ul>
    <li>I think that the version example is not the best- ideally we'd show a simple example that would work for all components, including extras lib and standard lib components. Maybe use something like '#zf display name' instead? That could also have a modifier to display FQN, package name, etc.</li>
    </ul>

    <ul>
    <li>What does this mean? "At process time, each actionable method inside a provider will be broken down into a series of signatures that will define the actionable method by the sum of its parts."</li>
    </ul>

    <ul>
    <li>What does this mean? "Providers also have a built in mechanism for allowing providers to break out their actionable methods into specialty areas."</li>
    </ul>

    <ul>
    <li>Why do we need specialties properties/methods? Seems like specialties would just be arguments on the action methods. Unless I'm missing something, this specialties mechanism adds a lot of unnecessary complexity.</li>
    </ul>

    <ul>
    <li>I can't stand the term "Metadatas". <ac:emoticon ac:name="smile" /> Data is already plural; I don't think I'm the only person this would bother. Can we call them "Metadata objects"?</li>
    </ul>

    <ul>
    <li>Why do we need an array of metadata objects? How would you extend these to provide support for new endpoints, etc.?</li>
    </ul>

    <ul>
    <li>Why do we need a separate provider registry and manifest registry. Isn't the distinction unimportant after the corresponding files have been loaded?</li>
    </ul>

    <ul>
    <li>I wonder if people will avoid classes with names in the pattern "*<ac:link ac:tooltip="Provider.php"><ri:page ri:content-title="Tool.php" /><ac:link-body>Manifest.php</ac:link-body></ac:link>" because they worry about affecting the performance of ZF tools. That would be very unfortunate as these are very useful terms for software components.</li>
    </ul>

    <ul>
    <li>What does "appended to the proper registry" mean?</li>
    </ul>

    <ul>
    <li>What namespace will the CLI endpoint implementation live in?</li>
    </ul>

    <ul>
    <li>Seems like Zend_Tool_Rpc_System_Provider_Version should be Zend_Tool_Rpc_Provider_System_Version, instead.</li>
    </ul>

    <p>In general:</p>

    <ul>
    <li>I'm not seeing why everything is in an RPC namespace. Seems like RPC is just a type of endpoint. The system might be analogous to how RPC works, but in the general case I don't believe it <strong>is</strong> RPC. If the method is called in the same process, I would just be confused by this naming. Why not just Zend_Tool_Endpoint, Zend_Tool_Loader, etc.? That also helps with the long class names.</li>
    </ul>

    <ul>
    <li>There are a few confusing typos.</li>
    </ul>

    1. Jun 30, 2008

      <blockquote>
      <ul>
      <li>Do providers just provide help, as implied in the Goals section, or do they actually expose interfaces to the functionality in question? I see the answer in the definitions, but it might help to clarify here.</li>
      </ul>
      </blockquote>

      <p>Changed above to reflect this in the goals.</p>

      <blockquote>
      <ul>
      <li>I think that the version example is not the best- ideally we'd show a simple example that would work for all components, including extras lib and standard lib components. Maybe use something like '#zf display name' instead? That could also have a modifier to display FQN, package name, etc.</li>
      </ul>
      </blockquote>

      <p>Lets chat about this, I am not sure I see what you are getting at yet. The purpose of the "version" example is to keep the purpose of the example simple enough to not get bogged down in what it delivers, but how it delivers it.. or better yet, to demonstrate the ease of extensibility.</p>

      <blockquote>
      <ul>
      <li>What does this mean? "At process time, each actionable method inside a provider will be broken down into a series of signatures that will define the actionable method by the sum of its parts."</li>
      </ul>

      <ul>
      <li>What does this mean? "Providers also have a built in mechanism for allowing providers to break out their actionable methods into specialty areas."</li>
      </ul>
      </blockquote>

      <p>This has been re-worded above.</p>

      <blockquote>
      <ul>
      <li>Why do we need specialties properties/methods? Seems like specialties would just be arguments on the action methods. Unless I'm missing something, this specialties mechanism adds a lot of unnecessary complexity.</li>
      </ul>
      </blockquote>

      <p>I see it is a pretty crucial element of the construction of a provider in situation where providers expose either complex or a wider variety of specialized methods. For example, if method names can only be "action" names, then you would have to have multiple classes to facilitate multiple logically different (for example) "create" commands within a component. This allows a provider to group several methods together and create a more concise API, thus allowing any one action to act upon "specialties" of a provider. If the provider realm is "WebService", the action is "create", then this allows us to describe specialties of things to create, like a "WSDL" or a "Controller-Action". This allows them to reside inside a single provider file.</p>

      <blockquote>
      <ul>
      <li>I can't stand the term "Metadatas". <ac:emoticon ac:name="smile" /> Data is already plural; I don't think I'm the only person this would bother. Can we call them "Metadata objects"?</li>
      </ul>
      </blockquote>

      <p>done. <ac:emoticon ac:name="smile" /></p>

      <blockquote>
      <ul>
      <li>Why do we need an array of metadata objects? How would you extend these to provide support for new endpoints, etc.?</li>
      </ul>

      <ul>
      <li>Why do we need a separate provider registry and manifest registry. Isn't the distinction unimportant after the corresponding files have been loaded?</li>
      </ul>

      </blockquote>

      <p>The term is better described as a "registry of metadata objects." First, its important to know the distinction and reasoning behind the separate registries. The two registries, Provider and Metadata, have distinctly different purposes, and contain distinctly different object types. The provider registry contains all the objects that define the "providers" in terms of "actionable methods". This is done by means of creating "Provider Signature" objects, and these objects are what make up the registry at "dispatch time". On the other hand, the Metadata registry is composed of all "metadata objects". Since the purpose and the structure of this Metadata Object is suited for "pre-dispatch" tasks (like alternate provider namings) and provider decoration, it has its own registry and is not directly tied to the Provider signatures. Furthermore, it should be said that the logical relationship between providers and metadata is not defined by means of one-to-many, one-to-one, or so on. There can be any number of metadata objects related to, or not related to any providers in the provider registry. What this means is that you are capable of creating Metadata objects that are not related to any providers, or are provider agnostic.</p>

      <p>As for the relationship to endpoints, its up to the endpoint implementation to create metadata objects. This can be seen in the Zend_Tool_Rpc_Endpoint_Cli_Metadata class.</p>

      <blockquote>
      <ul>
      <li>I wonder if people will avoid classes with names in the pattern "*Manifest.php" because they worry about affecting the performance of ZF tools. That would be very unfortunate as these are very useful terms for software components.</li>
      </ul>
      </blockquote>

      <p>Tool performance is not super high priority as its not a production time tool. Like Zend Studio, IDE's or even text editors, its for development time. Also, in future versions, we can introduce support for Zend_Cache which will allow us to cache the provider list and make the tool super perform-ant.</p>

      <blockquote>
      <ul>
      <li>What does "appended to the proper registry" mean?</li>
      </ul>
      </blockquote>

      <p>This means that Manfiest Classes will get loaded into the Manifest Registry, and Provider Classes will get loaded into the Provider registry. This is determined by the marker interface they implement (Zend_Tool_Rpc_Manifest_Interface / Zend_Tool_Rpc_Provider_Interface).</p>

      <blockquote>
      <ul>
      <li>What namespace will the CLI endpoint implementation live in?</li>
      </ul>
      </blockquote>

      <p>Zend_Tool_Rpc_Endpoint_Cli - this is demonstrated by the zf.php script:</p>

      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      require_once 'Zend/Loader.php';
      Zend_Loader::registerAutoload();

      Zend_Tool_Rpc_Endpoint_Cli::main();
      ]]></ac:plain-text-body></ac:macro>

      <blockquote>
      <ul>
      <li>Seems like Zend_Tool_Rpc_System_Provider_Version should be Zend_Tool_Rpc_Provider_System_Version, instead.</li>
      </ul>
      </blockquote>

      <p>Yes, one can make an argument for that. The idea behind the current naming is that the Zend_Tool_Rpc_Provider namespace is for Rpc system provider management whereas the Zend_Tool_Rpc_System namespace is an <strong>implementation</strong> of providers to be used by the Rpc system at rumtime, (for example, help and such). There will be more providers here in the near future.</p>

      <blockquote>
      <p>In general:</p>
      <ul>
      <li>I'm not seeing why everything is in an RPC namespace. Seems like RPC is just a type of endpoint. The system might be analogous to how RPC works, but in the general case I don't believe it <strong>is</strong>RPC. If the method is called in the same process, I would just be confused by this naming. Why not just Zend_Tool_Endpoint, Zend_Tool_Loader, etc.? That also helps with the long class names.</li>
      </ul>
      </blockquote>

      <p>The purpose of the Zend_Tool namespace is only to be a "namespace", Zend_Tool (speaking of this level), does not actually <strong>implement</strong> anything. Similar to what Zend_Service is, the implementations are inside the top level (Zend_Service) namespace.</p>

      <p>The other options here are names like Zend_RpcTool, Zend_CodeGeneratorTool, and Zend_ProjectTool. But this adds a level of complexity the the top level of the Zend Framework namespace.</p>

      <p>On a smaller note, I can argue that since Rpc is not defined by protocols, and is only a description of how a system works, I can argue this is Rpc. On of the principals of Rpc is "remote invocation". To satisfy this requirement, I could argue that the command line interface, just as Zend Studio, another IDE, or text editor could be the "remote" entity. In a technical sense, the actual method calls themselves are protected by the "endpoint" implementation, thus making all calls Rpc in nature.</p>

      1. Jul 01, 2008

        <p>This comment turned out to be much longer than I had planned. Please bear with me.</p>

        <p>I think the namespace Zend_Tool_Rpc is fine. The component enables clients (remote and local) to connect to the ZF application in a "remote" way, i.e. not via the paths taken by actual production users of the application.</p>

        <p>It also implies that calls are made in a remote procedure call fashion where the entire application context used for production users is not available. I see the tooling environment as having its own bootstrap file which may or may not initialize context for the application in the same way as the production bootstrap file.</p>

        <p>The Zend_Tool_Rpc Enpoints may not be used to provide RPC functionality that deals with executing business logic or retrieving/setting application data. It is strictly reserved to manipulating the implementation of the code/project NOT the content of it. It also may not provide admin functionality for the application which should reside in actual admin tools running within or in parallel to the application.</p>

        <p>I do however think that actual implementations of providers and their associated components should not reside in the Zend_Tool_Rpc namespace. They can be placed into something like Zend_Tool_Provider. The reason for this is that they have nothing to do with the implementation of the Zend_Tool_Rpc system itself but rather provide implementations of providers for the ZF system. While the RPC system is a great way to access these providers in an abstract way it does not mean that it will be the only system using the providers. It may even make sense to rename the interface for the providers to the Zend_Tool_Provider namespace to empower other tools to use these providers as well. There will be developers who will write their own set of providers that will not reside in the Zend_Tool namespace at all and the updated namespace would make this more consistent.</p>

        <p>Furthermore I think it will be important to be able to pass context/config information to providers explicitly rather than use the project config and context by default. Providers should only use config/context info specifically provided to them and not base it on the environment that is executing the Zend_Tool_Rpc call. For example, the Version provider above takes the version from Zend_Version::VERSION. Who is to say that the ZF code executing the provider is the same version as the ZF code used by the project? It should be beased on what the project is using. Another example. Say we have a provider that tests a database connection. The DB connection credentials need to be taken from the project config. What if we now want to test a new set of DB connection credentials? I should be able to pass the new info to the same provider, get a result and then if successful update the config.</p>

        <p>Providers must not require the overhead of Zend_Tool_Rpc but be able use the same interfaces. A good example for this would be a monitoring system. Say we have a component called Zend_Tool_Monitor. This system like Zend_Tool_Rpc knows how to use Zend_Tool_Providers as plugins for functionality. We develop a new monitoring component by testing it with Zend_Tool_Rpc and when everything is working hook it into Zend_Tool_Monitor. This will make the job of writing monitor plugins much simpler. Both systems will use the same Zend_Tool_Provider_Conext which is defined in the bootrap file or other stage when the Rpc and Monitoring systems get initialized. The monitor system must run MUCH more efficient than the Rpc system which will work as providers can get used independent of the abstract Rpc.</p>

        <p>Just like Zend_Tool_Rpc can be used with other frameworks I would like to see providers be used with other frameworks without requiring Zend_Tool_Rpc. Some frameworks have great command line tools and will not switch to Zend_Tool_Rpc as it does not fit with their current implementation. That does not mean that we cannot share functionality. We share functionality by defining a simple Zend_Tool_Provider standard that wraps tools. Other frameworks can then migrate their functionality to the provider standard, update their toolchain to use them and at the same time enable them to be used from ZF. This should require minimal work and could build a large set of providers that can be used by a number of frameworks.</p>

        <p>My 2cents.</p>

  4. Jul 11, 2008

    <p>Hi,</p>

    <p>after reading the proposal again and again I am still a bit puzzled.</p>

    <p>The components names don't really create the feeling of understanding in me. I liked the "resource", "action" naming scheme of the old Zend_Console proposal more. RPC, Manifest and Provider are very technical terms. Of course Zend_Tool is a technical component, but why make it harder than its already is? Also Endpoint is a term that rings no bell at all.</p>

    <p>Also in the examples, why is the Some3rdParty_Component_MyVersionTool class called with "zf show my-version"? How does Zend_Tool match the my-version string to the matching component? Perhaps its just a typo? Is this working like the creation and naming scheme of View Helpers?</p>

    <p>I do not understand why actionable methods and providers are reversed in the CLI call. If I implement a tool "MyTool" that has 3 actionable methods for example, "run configure help", isn't it confusing that you have to call them with:</p>

    <p>zf run mytool<br />
    zf configure mytool<br />
    zf help mytool</p>

    <p>In my understanding, this suggests that "run", "configure" and "help" are commands that are pre-existing independently of the Provider MyTool belonging to "zf" itself and it suggets that it is possible to exchange only the last part of the command with another tooling provider getting the same functionality.</p>

    1. Oct 16, 2008

      <p>I'm still having a hard time with the names, as well. But I will go along with whatever the community feels is best. I'll be asking the Zend_Tool focus group about this soon, so you might want to subscribe if you're not already.<br />
      I know why the actionable methods come before the providers. The tools tries to follow a 'subject verb object'. I think it is relatively intuitive that the provider has methods on it that act as the verb. In OOP it is common to have methods that act on the object on which they are defined.</p>

      <p>,Wil</p>

  5. Feb 06, 2011

    <p>Archiving this proposal, feel free to recover it when you want to work on it again. For more details see <a href="http://framework.zend.com/wiki/display/ZFDEV/Archiving+of+abandoned+proposals+(Feb+5+2011)">this email</a>.</p>