Added by Ralph Schindler, last edited by Ralph Schindler on Nov 13, 2008  (view change)

Labels

 
(None)

Zend Framework: Zend_Tool_Project Component Proposal

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

Table of Contents

1. Overview

Zend_Tool_Project is a component that facilitates Project based development through extending Zend_Tool_Framework.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will contain Providers for Zend_Tool_Framework to facilitate execution through the command line and various other endpoints.
  • This component will provide interfaces and abstracts that facilitate the extension of the base functionality related to "project" context nodes.
  • This component *wil

4. Dependencies on Other Framework Components

  • Zend_Tool_Framework
  • Zend_Tool_CodeGenerator
  • Zend_Exception
  • simplexml

5. Theory of Operation

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 providers for tooling framework interaction with the Project Profile with respect to Controller,Actions,View Scripts and other primary ZF Project elements.

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

This structure is capable of being parsed into the object graph by Zend_Tool_Project_Structure_Parser_Xml.

The Object Graph

The goal of the object graph (implemented as Zend_Tool_Project_Structure_Graph), 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 Zend_Tool_Project_Structure_Node(s), all of which should be decorated with a Node Context (Zend_Tool_Project_Structure_Context_Interface).

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 this filesystem context:

The nodes implemented would include the following list:

Context Name Where it Resides
ApplicationDirectory Zend_Tool_Project_Structure_Context_Zf_ApplicationDirectory
BootstrapFile Zend_Tool_Project_Structure_Context_Zf_BootstrapFile
ClassFileAbstract Zend_Tool_Project_Structure_Context_Zf_ClassFileAbstract
ControllerFile Zend_Tool_Project_Structure_Context_Zf_ControllerFileContextNode
ControllersDirectory Zend_Tool_Project_Structure_Context_Zf_ControllersDirectoryContextNode
HtaccessFile Zend_Tool_Project_Structure_Context_Zf_HtaccessFile
LibraryDirectory Zend_Tool_Project_Structure_Context_Zf_LibraryDirectory
ModelsDirectory Zend_Tool_Project_Structure_Context_Zf_ModelsDirectory
ModulesDirectory Zend_Tool_Project_Structure_Context_Zf_ModulesDirectory
ProjectDirectory Zend_Tool_Project_Structure_Context_Zf_ProjectDirectory
PublicDirectory Zend_Tool_Project_Structure_Context_Zf_PublicDirectory
PublicIndexFile Zend_Tool_Project_Structure_Context_Zf_PublicIndexFile
ViewControllerScriptsDirectory Zend_View_Tool_ViewControllerScriptsDirectory
ViewFiltersDirectory Zend_Tool_Project_Structure_Context_Zf_ViewFiltersDirectory
ViewHelpersDirectory Zend_Tool_Project_Structure_Context_Zf_ViewHelpersDirectory
ViewScriptFile Zend_Tool_Project_Structure_Context_Zf_ViewScriptFile
ViewScriptsDirectory Zend_Tool_Project_Structure_Context_Zf_ViewScriptsDirectory
ViewsDirectory Zend_Tool_Project_Structure_Context_Zf_ViewsDirectory
ZendFrameworkStandardLibrary Zend_Tool_Project_Structure_Context_Zf_ZendFrameworkStandardLibrary

There are also some base contexts that have been created to facilitate filesystem based operation

Context Name Where it Resides
Directory Zend_Tool_Project_Structure_Filesystem_Directory
File Zend_Tool_Project_Structure_Filesystem_File

The Providers

To expose the manipulation of the object graph to the end user, this component makes use of the Zend_Tool_Framework 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.

In the above example of creating a new controller, it is important to describe the relationship between providers and contexts. Being able to say "zf create controller", means that here is a "Controller Provider" available, which has an actionable method named "create". In terms of code, this means that the following exists: Zend_Controller_Tool_ControllerProvider::create() (consequently, this class extends Zend_Tool_Project_Provider_Abstract). This method is responsible taking the object graph created by the base class Zend_Tool_Project_Provider_Abstract, interacting with it (by means of creating a new controller node in much the same way one would create a new node in a DomDocument), and writing the profile back to disk (also another function of the base abstract Zend_Tool_Project_Provider_Abstract class.)

6. Milestones / Tasks

Describe some intermediate state of this component in terms of design notes, additional material added to this page, and / code. Note any significant dependencies here, such as, "Milestone #3 can not be completed until feature Foo has been added to ZF component XYZ." Milestones will be required for acceptance of future proposals. They are not hard, and many times you will only need to think of the first three below.

  • 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_Project_Provider
  • Zend_Tool_Project_Provider_Abstract
  • Zend_Tool_Project_Provider_Manifest
  • Zend_Tool_Project_Provider_Project
  • Zend_Tool_Project_Structure
  • Zend_Tool_Project_Structure_Context
  • Zend_Tool_Project_Structure_Context_Exception
  • Zend_Tool_Project_Structure_Context_Filesystem
  • Zend_Tool_Project_Structure_Context_Filesystem_Abstract
  • Zend_Tool_Project_Structure_Context_Filesystem_Directory
  • Zend_Tool_Project_Structure_Context_Filesystem_File
  • Zend_Tool_Project_Structure_Context_Interface
  • Zend_Tool_Project_Structure_Context_Registry
  • Zend_Tool_Project_Structure_Context_Zf
  • Zend_Tool_Project_Structure_Context_Zf_ApisDirectory
  • Zend_Tool_Project_Structure_Context_Zf_ApplicationDirectory
  • Zend_Tool_Project_Structure_Context_Zf_BootstrapFile
  • Zend_Tool_Project_Structure_Context_Zf_CacheDirectory
  • Zend_Tool_Project_Structure_Context_Zf_ConfigsDirectory
  • Zend_Tool_Project_Structure_Context_Zf_DataDirectory
  • Zend_Tool_Project_Structure_Context_Zf_HtaccessFile
  • Zend_Tool_Project_Structure_Context_Zf_LayoutsDirectory
  • Zend_Tool_Project_Structure_Context_Zf_LibraryDirectory
  • Zend_Tool_Project_Structure_Context_Zf_LocalesDirectory
  • Zend_Tool_Project_Structure_Context_Zf_LogsDirectory
  • Zend_Tool_Project_Structure_Context_Zf_ModelsDirectory
  • Zend_Tool_Project_Structure_Context_Zf_ModulesDirectory
  • Zend_Tool_Project_Structure_Context_Zf_ProjectDirectory
  • Zend_Tool_Project_Structure_Context_Zf_ProjectProfileFile
  • Zend_Tool_Project_Structure_Context_Zf_ProvidersDirectory
  • Zend_Tool_Project_Structure_Context_Zf_PublicDirectory
  • Zend_Tool_Project_Structure_Context_Zf_PublicImagesDirectory
  • Zend_Tool_Project_Structure_Context_Zf_PublicIndexFile
  • Zend_Tool_Project_Structure_Context_Zf_PublicScriptsDirectory
  • Zend_Tool_Project_Structure_Context_Zf_PublicStylesheetsDirectory
  • Zend_Tool_Project_Structure_Context_Zf_SearchIndexesDirectory
  • Zend_Tool_Project_Structure_Context_Zf_SessionsDirectory
  • Zend_Tool_Project_Structure_Context_Zf_TemporaryDirectory
  • Zend_Tool_Project_Structure_Context_Zf_TestsDirectory
  • Zend_Tool_Project_Structure_Context_Zf_UploadsDirectory
  • Zend_Tool_Project_Structure_Context_Zf_ZfStandardLibraryDirectory
  • Zend_Tool_Project_Structure_Exception
  • Zend_Tool_Project_Structure_Graph
  • Zend_Tool_Project_Structure_Node
  • Zend_Tool_Project_Structure_Parser
  • Zend_Tool_Project_Structure_Parser_Interface
  • Zend_Tool_Project_Structure_Parser_Xml

8. Use Cases

UC-01

9. Class Skeletons

Comments  (Hide Comments)

Specifics:

  • Doesn't address how the project profile would be updated well enough.
  • I don't see why we need a CommandSystem package.
  • With a context node registry, I've now counted 3 separate registries including those defined in the Zend_Tool_Rpc proposal. I can see justifications for this one and a manifest registry. The number of registries may indicate an overly complex design.
  • Both requirements and dependencies need to be filled out.
  • I don't get a clear picture of how context nodes and providers work together from the description. How are they instantiated and managed, for example?
  • We need some use cases to help understand what we're trying to accomplish here.

General:

  • Need to review to make sure this reflects latest thoughts.
  • There are a few confusing typos.
  • I think the namespaces could be reorganized to better reflect responsibilities of the separate components.
Posted by Wil Sinclair at Jun 24, 2008 04:33
  • Doesn't address how the project profile would be updated well enough.

The project profile file is updated from within the provider after any object graph interaction has been completed (See use case 1)

  • I don't see why we need a CommandSystem package.

Artifacts, they were removed and renamed

  • With a context node registry, I've now counted 3 separate registries including those defined in the Zend_Tool_Rpc proposal. I can see justifications for this one and a manifest registry. The number of registries may indicate an overly complex design.

Complex design, yes. Overly? I don't think so. I think there is enough separation here to facilitate future development. The benefit of this design is that developers dont have to know ALL aspects of the system to start becoming productive in it. By and large, these registries are transparent objects to the developer extending the system and are completely transparent to the end users (people interacting with the endpoints: zf create controller), etc. Merging registries would start to produce a glob of objects that have no common purpose. Also, having more less purposeful objects in a more global registry would prove to be difficult to debug for developers creating new "project contexts" and/or providers.

  • Both requirements and dependencies need to be filled out.

I have no idea what happened here, copy and paste must have gone awry.

  • I don't get a clear picture of how context nodes and providers work together from the description. How are they instantiated and managed, for example?

Updated in the "The Providers" section. (and moved first.)

  • We need some use cases to help understand what we're trying to accomplish here.

see above

General:

  • I think the namespaces could be reorganized to better reflect responsibilities of the separate components.

What suggestions do you have?

Posted by Ralph Schindler at Jun 30, 2008 09:54

I like the concepts that are being worked on with this. I'd like to see the ability to update the current directory structure if the .zfproject.xml is updated. eg: zf update project in the instance that one has updated the xml file manually, and need to put those changes into action in the directory structure.

Posted by Jay M. Keith at Jul 08, 2008 08:52

Hi Ralph - just to point out the similar sentiment on the Quickstart page. The schema seems to be overly complex for a human editable format. Is there any way we can simplify this and place more reliance on attributes? I understand the current form is easier on classname mapping - but mapping is a purely implementation related concern. As such, a greater emphasis on making the syntax more user and edit friendly would be far more worthwhile.

Posted by Pádraic Brady at Jul 11, 2008 01:22

One thing that I don't see from UC-01 (and I might be missing it) is the creation of the controller directory if it's not there. It seems to me that any provider should recursive find or create its parents.
It's also not clear to me how nodes and contexts are different. What are the responsibilities of each?

Posted by Wil Sinclair at Oct 16, 2008 15:02