compared with
Current by Ralph Schindler
on May 16, 2008 09:42.

Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (71)

View Page History
h1. Zend_Tool_Project
<h1>Zend_Tool_Project</h1>

h2. Goals
<h2>Goals</h2>

The goals of Zend_Tool_Project is two fold:
<p>The goals of Zend_Tool_Project is two fold:</p>
<ul>
* provide <li>provide a suite of functionality that can build, modify, and serialize an object graph representation of various nodes/elements within a Zend Framework oriented project, also known as a "Project Profile". &quot;Project Profile&quot;.</li>
* a registry for project context nodes (ie the names of the nodes in the xml file)
<li>a registry for project context nodes (ie the names of the nodes in the xml file)</li>
* provide <li>provide a set of Zend_Tool_CommandSystem_Providers that will expose the interaction with a projects object graph to a Tooling Client through the Zend_Tool_CommandSystem.</li>
</ul>

h2. The Serialization Format

The primary serialization format needs to support recursive nodes with a varying amount of attributes further defining that nodes context. The primary format that fully meets this expectation is XML. Furthermore, PHP has basic classes in the SPL that facilitate and support XML as an object graph, specifically the RecursiveIterator. It is for this reason that the primary serialization medium will be XML. This is not to say that future formats will/can not be supported, only that XML will be the first and primary format.
<h2>The Serialization Format</h2>

An example of a serialized project profile:
<p>The primary serialization format needs to support recursive nodes with a varying amount of attributes further defining that nodes context. The primary format that fully meets this expectation is XML. Furthermore, PHP has basic classes in the SPL that facilitate and support XML as an object graph, specifically the RecursiveIterator. It is for this reason that the primary serialization medium will be XML. This is not to say that future formats will/can not be supported, only that XML will be the first and primary format.</p>

<code>
<p>An example of a serialized project profile:</p>

<p>This profile taken from <a href="http://framework.zend.com/wiki/display/ZFPROP/Zend+Framework+Default+Project+Structure+-+Wil+Sinclair">http://framework.zend.com/wiki/display/ZFPROP/Zend+Framework+Default+Project+Structure+-+Wil+Sinclair</a></p>

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

<?xml version="1.0"?>
<projectProfile>
<projectProfileFile/>
<applicationDirectory name="application">
<apisDirectory enabled="false" />
<configDirectory enabled="false" />
<controllersDirectory name="controllers">
<controllerFile name="index"/>
</controllersDirectory>
<modelsDirectory name="models"/>
<layoutsDirectory enabled="false" />
<modelsDirectory />
<modulesDirectory name="modules"/>
<viewsDirectory name="views">
<viewScriptsDirectory name="scripts">
<viewFiltersDirectory name="filters"/>
</viewsDirectory>
<modulesDirectory name="modules"/>
<bootstrapFile name="bootstrap.php"/>
</applicationDirectory>
<dataDirectory enabled="false"/>
<libraryDirectory name="library">
<zendFrameworkStandardLibrary name="Zend"/>
</projectProfile>

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

h2. The Object Graph
<h2>The Object Graph</h2>

<p>The goal of the object graph (implemented as Zend_Tool_Project_ProjectProfile), is to be able to serialize and unserialize the project's structure (See above) into an object graph that can be modified in runtime. This object graph is made up of ProjectCOntext nodes, all of which extent a common abstract (Zend_Tool_Project_ProjectContextAbstract).</p>

<p>TO understand how these peices fit together, here is the class for ProjectProfile:</p>

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

<?php
}

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

And the context abstract:
<p>And the context abstract:</p>


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

abstract class Zend_Tool_Project_ProjectContextAbstract implements RecursiveIterator, Countable
}

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

h2. The Context Node Registry
<h2>The Context Node Registry</h2>

<p>Providers will be responsible for registering context nodes within the registry for later use within a project profile. There can only be a node available of a singular name, for example, only one node named 'controllerFile' should exist in the registry. The registry would allow overwriting of a contextNode if and only if an overwrite flag was passed at set time.</p>

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

class Zend_Tool_Project_ContextNode_Registry extends Zend_Registry
{}

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

h2. The Filesystem ProjectContext Nodes
<h2>The Filesystem ProjectContext Nodes</h2>

<p>Assuming the above abstracts, the first order of business is to implement context nodes for the purposes of creating, modifying and deleting filesystem nodes. This includes (but is not limited to) controllers, bootstrap files, the Zend Framework library, view scripts, models and the .htaccess file to name a few. There exists a default abstract for thsi filesystem context:</p>

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

<?php
}

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

<p>The nodes implemented would include the following list:</p>

|| Context Name || Where it Resides ||
|ApplicationDirectory |Zend_Tool_Project_ContextNode_ApplicationDirectory|
<table><tbody>
<tr>
<th><p> Context Name </p></th>
<th><p> Where it Resides </p></th>
</tr>
<tr>
<td><p>ApplicationDirectory </p></td>
<td><p>Zend_Tool_Project_ContextNode_ApplicationDirectory</p></td>
</tr>
<tr>
<td><p>BootstrapFile </p></td>
<td><p>Zend_Tool_Project_ContextNode_BootstrapFile</p></td>
</tr>
<tr>
<td><p>ClassFileAbstract </p></td>
<td><p>Zend_Tool_Project_ContextNode_ClassFileAbstract</p></td>
</tr>
<tr>
<td><p>ControllerFile </p></td>
<td><p>Zend_Controller_Tool_ControllerFileContextNode</p></td>
</tr>
<tr>
<td><p>ControllersDirectory </p></td>
<td><p>Zend_Controller_Tool_ControllersDirectoryContextNode</p></td>
</tr>
<tr>
<td><p>Directory </p></td>
<td><p>Zend_Tool_Project_ContextNode_Directory</p></td>
</tr>
<tr>
<td><p>File </p></td>
<td><p>Zend_Tool_Project_ContextNode_File</p></td>
</tr>
<tr>
|BootstrapFile <td><p>HtaccessFile |Zend_Tool_Project_ContextNode_BootstrapFile| </p></td>
|ClassFileAbstract |Zend_Tool_Project_ContextNode_ClassFileAbstract|
|ControllerFile |Zend_Controller_Tool_ControllerFileContextNode|
|ControllersDirectory |Zend_Controller_Tool_ControllersDirectoryContextNode|
|Directory |Zend_Tool_Project_ContextNode_Directory|
|File |Zend_Tool_Project_ContextNode_File|
|HtaccessFile |Zend_Tool_Project_ContextNode_HtaccessFile|
|LibraryDirectory |Zend_Tool_Project_ContextNode_LibraryDirectory|
|ModelsDirectory |Zend_Tool_Project_ContextNode_ModelsDirectory|
|ModulesDirectory |Zend_Tool_Project_ContextNode_ModulesDirectory|
|ProjectDirectory |Zend_Tool_Project_ContextNode_ProjectDirectory|
|PublicDirectory |Zend_Tool_Project_ContextNode_PublicDirectory|
|PublicIndexFile |Zend_Tool_Project_ContextNode_PublicIndexFile|
|ViewControllerScriptsDirectory |Zend_View_Tool_ViewControllerScriptsDirectory|
|ViewFiltersDirectory |Zend_View_Tool_ViewFiltersDirectory|
|ViewHelpersDirectory |Zend_View_Tool_ViewHelpersDirectory|
|ViewScriptFile |Zend_View_Tool_ViewScriptFile|
|ViewScriptsDirectory |Zend_View_Tool_ViewScriptsDirectory|
|ViewsDirectory |Zend_View_Tool_ViewsDirectory|
|ZendFrameworkStandardLibrary |Zend_Tool_Project_ContextNode_ZendFrameworkStandardLibrary|
<td><p>Zend_Tool_Project_ContextNode_HtaccessFile</p></td>
</tr>
<tr>
<td><p>LibraryDirectory </p></td>
<td><p>Zend_Tool_Project_ContextNode_LibraryDirectory</p></td>
</tr>
<tr>
<td><p>ModelsDirectory </p></td>
<td><p>Zend_Tool_Project_ContextNode_ModelsDirectory</p></td>
</tr>
<tr>
<td><p>ModulesDirectory </p></td>
<td><p>Zend_Tool_Project_ContextNode_ModulesDirectory</p></td>
</tr>
<tr>
<td><p>ProjectDirectory </p></td>
<td><p>Zend_Tool_Project_ContextNode_ProjectDirectory</p></td>
</tr>
<tr>
<td><p>PublicDirectory </p></td>
<td><p>Zend_Tool_Project_ContextNode_PublicDirectory</p></td>
</tr>
<tr>
<td><p>PublicIndexFile </p></td>
<td><p>Zend_Tool_Project_ContextNode_PublicIndexFile</p></td>
</tr>
<tr>
<td><p>ViewControllerScriptsDirectory </p></td>
<td><p>Zend_View_Tool_ViewControllerScriptsDirectory</p></td>
</tr>
<tr>
<td><p>ViewFiltersDirectory </p></td>
<td><p>Zend_View_Tool_ViewFiltersDirectory</p></td>
</tr>
<tr>
<td><p>ViewHelpersDirectory </p></td>
<td><p>Zend_View_Tool_ViewHelpersDirectory</p></td>
</tr>
<tr>
<td><p>ViewScriptFile </p></td>
<td><p>Zend_View_Tool_ViewScriptFile</p></td>
</tr>
<tr>
<td><p>ViewScriptsDirectory </p></td>
<td><p>Zend_View_Tool_ViewScriptsDirectory</p></td>
</tr>
<tr>
<td><p>ViewsDirectory </p></td>
<td><p>Zend_View_Tool_ViewsDirectory</p></td>
</tr>
<tr>
<td><p>ZendFrameworkStandardLibrary </p></td>
<td><p>Zend_Tool_Project_ContextNode_ZendFrameworkStandardLibrary</p></td>
</tr>
</tbody></table>

As you can see, the names of these project contexts would all extend the File (or Directory) project context, which consequently extends the FilesystemAbstract project context. You can also see that the names listed above match up with what is defined out inside our example serialization file (inside the first section of this proposal.) File and Directory would be responsible for implementing the actual calls to, for example, file_put_contents, unlink, mkdir and rmdir.

<p>As you can see, the names of these project contexts would all extend the File (or Directory) project context, which consequently extends the FilesystemAbstract project context. You can also see that the names listed above match up with what is defined out inside our example serialization file (inside the first section of this proposal.) File and Directory would be responsible for implementing the actual calls to, for example, file_put_contents, unlink, mkdir and rmdir.</p>

h2. The Providers

To expose the manipulation of the object graph to the end user, this component makes use of the Zend_Tool_CommandSystem Provider hooks in order to extend these capabilities outward. If, for example, from the command line, a user wanted to create a new "user" controller and the resulting view script, it would be ideal if the user could do: zf create controller -n user. The way Zend_Tool_Project would expose that capability would be through implementing a provider for that action.
<h2>The Providers</h2>

Below is the provider that would implement that command:
<p>To expose the manipulation of the object graph to the end user, this component makes use of the Zend_Tool_CommandSystem Provider hooks in order to extend these capabilities outward. If, for example, from the command line, a user wanted to create a new &quot;user&quot; controller and the resulting view script, it would be ideal if the user could do: zf create controller -n user. The way Zend_Tool_Project would expose that capability would be through implementing a provider for that action.</p>

{code}
<p>Below is the provider that would implement that command:</p>

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

<?php

}

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