Zend_Tool_Project

Goals

The goals of Zend_Tool_Project is two fold:

• 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".
• a registry for project context nodes (ie the names of the nodes in the xml file)
• 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.

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.

An example of a serialized project profile:

This profile taken from http://framework.zend.com/wiki/display/ZFPROP/Zend+Framework+Default+Project+Structure+-+Wil+Sinclair

The Object Graph

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).

TO understand how these peices fit together, here is the class for ProjectProfile:

And the context abstract:

The Context Node Registry

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.

The Filesystem ProjectContext Nodes

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:

The nodes implemented would include the following list:

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.

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.

Below is the provider that would implement that command: