Skip to end of metadata
Go to start of metadata

<p>Ralph's Critical Evaluation of General Architecture</p>

<h3>1. The use of the Zend_Build namespace</h3>

<p>In a classical sense, a build system has been defined as a system by which projects, targets and tasks work together in a non-interactive way to execute a requested set of goals. Products in the same vertical include Make, Ant (Java), Phing (PHP), Nant (.net), Rake (Ruby). Of that list, make uses GNU-Makefile bash-like syntax; and the ant variants (ant, phing, nant) use xml as the syntactical language for describing projects, targets and tasks. Lastly, Rake (IMO) is by far the most interesting. Rake allows developers to create project file in valid Ruby syntax. </p>

<p>The important thing to take away from rake is that rake allows ruby developers to stay in ruby for their projects.</p>

<p>The common problem from the PHP community I hear is that the 1) the idea of a build system is counter intuitive since you dont actually compile php and 2) the structure of phing documents has a learning curve that is a bit steep for the standard PHP developer and their mindset.</p>

<p>Of those people in the mindset of concern 1.. These people (in their production-corporate environments) have Perl scripts or PHP scripts handling Build-like tasks.. each with massive switch statements, if clauses, etc. There is very little commonality or structure from one script to the next.</p>

<p>Currently, Zend_Build in its current state is redefining the common terminology that is associated with existing build solutions. Instead of Projects, Targets and Tasks, we are introducing new terms like Actions and Resources. While I am much a fan of Actions and Resources as an element of the Command Line Tool system, I am not sure if they are best placed at the moment within Zend_Build.</p>

<p>I propose that we examine the possibility of creating a real PHP based build system. The major requirements are that we keep the existing build terminologies (project, target, task) and that the system can be defined completely in PHP. This allows use to leverage existing ideologies as well as allows the developers to stay within the language of their projects choice. This system can draw on the logical organization and runners with PHPUnit.</p>

<p>Details</p>

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

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

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

<p>In order to preserve the notions of the Command Line Tooling, we should move Actions and Resources to where they belong, inside of Zend_Tool_Action and Zend_Tool_Resource.</p>

<h3>2. The necessity of Action objects</h3>

<p>In development, I am having a hard time justifying the need for full-fledged action objects when actions could simply be methods within a resource. A good argument for them is that general "Action" usage, parameter requirements (even though really solid examples have yet to bubble up) can be isolated into a singular class/object for said Action.</p>

<h3>3. Design Decisions implied by Assumption of interactivity of Zend Studio</h3>

<p>A couple of design decision seemingly proposed by the prospect of Zend Studio integration is that of "how" (which is largely undefined as of yet and of much speculation) ZS will interact with the Command Line Tools and the Tooling subsystem.</p>

<p>One design decision is the use of XML as the Manifest files. A strong vote for this decision is that outside tools will be able to read xml (presumably), so that they can better interact with the zf.php. I feel like we should re-examine the use of XML as a manifest language since this deviates from the rest of the framework with is PHP centric. </p>

<p>In keeping consistency with the framework, I would propose that we come up with an Interface and/or an Abstract class for gathering Action and Resource parameter requirements, usage details, and so on. I would also propose that a Zend_Tool_Manifest file could be placed in the include path such that by a conventional name (like XXX-ZFToolManfest.php), it could be found, loaded and utilized by the tooling system; in much the same way that the existing xml files are.</p>

<p>This above proposal is NOT to say that xml will not be supported (in its current form), and should be supported in cases where people wishing to extend the Command Line Tool wish to use xml in place of a class/object. </p>

<p>In order to support unknown tooling options, I feel like we should explore the next proposal.</p>

<h3>4. XMLRPC (for action and resource pairs) for non-cli subsystems</h3>

<p>XML-RPC is a fairly common RPC protocol for not only exchanging data but executing methods. This protocol, as well as its adoption in the web world make it a good fit with this Command Line Tool, specifically with requesting actions/resources to be executed.</p>

<p>Also, since ZF has a solid XML-RPC Server and Client, this makes interoperability a cinch. </p>

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