compared with
Current by Ralph Schindler
on May 15, 2008 08:45.

(show comment)
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (90)

View Page History

h1. Zend_Tool_Rpc
<h1>Zend_Tool_Rpc</h1>

h2. Goals
<h2>Goals</h2>

Zend_Tool_Rpc is a framework that provides:
<p>Zend_Tool_Rpc is a framework that provides:</p>
<ul>
* common <li>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" (1). &quot;tooling clients&quot; (1).</li>
* Implementation of "endpoints" (5) to be used to connect "tooling clients" to the Zend_Tool_Rpc, the primary endpoint implementation being that of the "Command Line Interface Endpoint" (6)
<li>Implementation of &quot;endpoints&quot; (5) to be used to connect &quot;tooling clients&quot; to the Zend_Tool_Rpc, the primary endpoint implementation being that of the &quot;Command Line Interface Endpoint&quot; (6)</li>
* Implement <li>Implement a stardard set of "providers" &quot;providers&quot; (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". &quot;Help System&quot;.</li>
</ul>

In a more general sense, Zend_Tool_Rpc 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."
<p>In a more general sense, Zend_Tool_Rpc 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: </p>

h2. The subsystems that make up Zend_Tool_Rpc
<p>&quot;Dont work harder, work smarter.&quot;</p>

h3. Zend_Tool_Rpc_Provider & Zend_Tool_Rpc_ProviderAbstract
<h2>The subsystems that make up Zend_Tool_Rpc</h2>

Zend_Tool_Rpc_Provider represents the functional or "capability" aspect of the Zend_Tool_Rpc framework. Fundamentally, Zend_Tool_Rpc_Provider will provide the interfaces and abstracts necessary to produce "providers", or bits of tooling functionality, that can be called and used inside the Zend_Tool_Rpc toolchain. The simplistic nature of extending this "provider abstract" allows the developer a "one-stop-shop" of adding functionality/capabilities to the Zend_Tool_Rpc.
<h3>Zend_Tool_Rpc_Provider &amp; Zend_Tool_Rpc_ProviderAbstract</h3>

Here is the abstract for the provider to get a sense for what this sub-system is responsible for:
<p>Zend_Tool_Rpc_Provider represents the functional or &quot;capability&quot; aspect of the Zend_Tool_Rpc framework. Fundamentally, Zend_Tool_Rpc_Provider will provide the interfaces and abstracts necessary to produce &quot;providers&quot;, or bits of tooling functionality, that can be called and used inside the Zend_Tool_Rpc toolchain. The simplistic nature of extending this &quot;provider abstract&quot; allows the developer a &quot;one-stop-shop&quot; of adding functionality/capabilities to the Zend_Tool_Rpc.</p>

<p>Here is the abstract for the provider to get a sense for what this sub-system is responsible for:</p>
{code}
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
<?php

}

{code}
]]></ac:plain-text-body></ac:macro>


<p>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 extend Zend_Tool_Rpc_ProviderAbstract and the body of this file would only have to look like the following:</p>

{code}
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
class Some3rdParty_Component_MyZfTool extends Zend_Tool_Rpc_ProviderAbstract
{
}

{code}
]]></ac:plain-text-body></ac:macro>

<p>Given that code above, and assuming the developer wishes to access this functionilty through the Command Line Tooling Client, the call would look like this:</p>

#zf show my-zf-tool.datafile-version
<p>#zf show my-zf-tool.datafile-version<br />
Version number is: 4.0</p>


h3. Zend_Tool_Rpc_Registry
<h3>Zend_Tool_Rpc_Registry</h3>

<p>The Zend_Tool_Rpc_Registry is a runtime bootstrapped registry of all available providers and manifestation metadata.</p>


h3. Zend_Tool_Rpc_Registry_Loader
<h3>Zend_Tool_Rpc_Registry_Loader</h3>

<p>The purpose of the Registry Loader is to find Providers and Manifest files within the php include_path who's file names match a specific set of patterns and implement/extend either Zend_Tool_Rpc_ProviderAbstract or Zend_Tool_Rpc_ManifestInterface. Once these files are found, the providers are loaded into the Provider Registry and manifest metadata is loaded into the Manifest Registry.</p>

<p>Currently, it has been decided that the file names to be search for (which will be configurable), will be *Tool.php and *Manifest.php. The registry loader will make use of RecursiveDirectoryIterator as well as RecursiveFilterIterator in order to find which files match the patterns described. </p>


h3. Zend_Tool_Rpc_ManifestInterface
<h3>Zend_Tool_Rpc_ManifestInterface</h3>

<p>Zend_Tool_Rpc_Manifest provides the means by which those creating providers and endpoint can decorate providers in such a way that is consumable and reusable by all components within the system. The interface for the files implementing a manifest is below (also remember this file should be named *Manifest.php in order to be found and parsed when the tooling systme bootstraps.)</p>

{code}
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
<?php


}
{code}
]]></ac:plain-text-body></ac:macro>



h2. Zend_Tool_Rpc_Endpoint
<h2>Zend_Tool_Rpc_Endpoint</h2>

<p>Zend_Tool_Rpc_Endpoint is the externally exposed interface that consumers are expected interact with the Zend_Tool_Rpc 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 executing an action 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 implementation.</p>

{code}
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
<?php


}
{code}
]]></ac:plain-text-body></ac:macro>

h3. Zend_Tool_Rpc_Endpoint_Cli & Zend_Tool_Rpc_Endpoint_Rpci
<h3>Zend_Tool_Rpc_Endpoint_Cli &amp; Zend_Tool_Rpc_Endpoint_Rpci</h3>

<p>The command line interface endpoint shall make use of the command line arguments to initiate the action/provider) request, and also make use of standard out to alert the user of any output that came from the exection of the provider.</p>

<p>XXXXXXXXXXXXXXXX<br />
XXXXXXXXXXXXXXXX Discuss Rcpi endpoint<br />
XXXXXXXXXXXXXXXX<br />
XXXXXXXXXXXXXXXX<br />
XXXXXXXXXXXXXXXX</p>
XXXXXXXXXXXXXXXX Discuss Rcpi endpoint
XXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXX


h2. Zend_Tool_Rpc_Provider's built in providers
<h2>Zend_Tool_Rpc_Provider's built in providers</h2>

<p>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.</p>

* System
* Test

XXXXXXXXXXXXXXXX <ul>
XXXXXXXXXXXXXXXX Talk about internal methods
XXXXXXXXXXXXXXXX <li>System</li>
XXXXXXXXXXXXXXXX <li>Test</li>
XXXXXXXXXXXXXXXX </ul>


<p>XXXXXXXXXXXXXXXX<br />
XXXXXXXXXXXXXXXX Talk about internal methods<br />
XXXXXXXXXXXXXXXX<br />
XXXXXXXXXXXXXXXX<br />
XXXXXXXXXXXXXXXX</p>




h2. Definitions and Terms

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

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

(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_Rpc_Endpoint"
<h2>Definitions and Terms</h2>

(5) Endpoint - The subsystem of "Zend Tool" that exposes an interface such that "tooling clients" can connect, query and execute commands.
<p> (1) Zend_Tool_Rpc - The framework which exposes tooling capabilities.</p>
(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".
<p> (2) Tooling Client - A developer tool that connects to and consumes &quot;Zend_Tool_Rpc&quot;.</p>
(8) Provider - A subsystem and a collection of built-in functionality that the "Zend Tool" system exports.

<p> (3) Command Line Tool / Command Line Interface / zf.php - The &quot;tooling client&quot; for the command line.</p>

<p> (4) Zend Studio - An IDE based &quot;tooling client&quot;, connects via the RPC &quot;Zend_Tool_Rpc_Endpoint&quot;</p>

<p> (5) Endpoint - The subsystem of &quot;Zend Tool&quot; that exposes an interface such that &quot;tooling clients&quot; can connect, query and execute commands.</p>

<p> (6) Cli Endpoint - An endpoint implementation responsible for exposing &quot;Zend Tool RPC&quot; via the &quot;command line interface&quot;.</p>

<p> (7) Rpci Endpoint - An endpoint implementation responsible for exposing &quot;Zend Tool RPC&quot; via the &quot;remote procedure call interface&quot;.</p>

<p> (8) Provider - A subsystem and a collection of built-in functionality that the &quot;Zend Tool&quot; system exports.</p>

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

(10) Manifest - A subsystem for defining, organizing, and disseminating "provider" requirement data.
<p> (10) Manifest - A subsystem for defining, organizing, and disseminating &quot;provider&quot; requirement data.</p>