Przeglądaj źródła

[DOCUMENTATION] English:
- manual fixes

git-svn-id: http://framework.zend.com/svn/framework/standard/trunk@16656 44c647ce-9c0f-0410-b52a-842ac1e357ba

mikaelkael 16 lat temu
rodzic
commit
fd4b537038

+ 34 - 32
documentation/manual/en/module_specs/Zend_Tool_Framework-Architecture.xml

@@ -8,7 +8,7 @@
 
         <para>
             Because providers and manifests may come from anywhere in the
-            <code>include_path</code>, a registry is provided to simplify access
+            <property>include_path</property>, a registry is provided to simplify access
             to the various pieces of the toolchain. This registry is injected
             into registry-aware components, which may then pull dependencies
             from them as necessary. Most dependencies registered with the
@@ -78,7 +78,7 @@ interface Zend_Tool_Framework_Registry_EnabledInterface
             functionality that can be called and used inside the
             <classname>Zend_Tool_Framework</classname> toolchain. The simplistic nature of
             implementing this provider interface allows the developer a
-            "one-stop-shop" of adding functionality/capabilities to
+            "one-stop-shop" of adding functionality or capabilities to
             <classname>Zend_Tool_Framework</classname>.
         </para>
 
@@ -118,9 +118,9 @@ abstract class Zend_Tool_Framework_Provider_Abstract
         <para>
             The purpose of a Loader is to find Providers and Manifest files that
             contain classes which implement either
-            <code>Zend_Tool_Framework_Provider_Interface</code> or
-            <code>Zend_Tool_Framework_Manifest_Interface</code>. Once these files are found
-            by a loader, providers are loaded into the Provider Repository and
+            <classname>Zend_Tool_Framework_Provider_Interface</classname> or
+            <classname>Zend_Tool_Framework_Manifest_Interface</classname>. Once these files are
+            found by a loader, providers are loaded into the Provider Repository and
             manifest metadata is loaded into the Manifest Repository.
         </para>
 
@@ -142,17 +142,17 @@ abstract class Zend_Tool_Framework_Loader_Abstract
 ]]></programlisting>
 
         <para>
-            The <code>_getFiles()</code> method should return an array of files (absolute
-            paths). The built-in loader supplied with ZF is called the
+            The <methodname>_getFiles()</methodname> method should return an array of files
+            (absolute paths). The built-in loader supplied with Zend Framework is called the
             IncludePath loader. By default, the Tooling framework will use an
             include_path based loader to find files that might include Providers
             or Manifest Metadata objects.
-            <code>Zend_Tool_Framework_Loader_IncludePathLoader</code>, without
+            <classname>Zend_Tool_Framework_Loader_IncludePathLoader</classname>, without
             any other options, will search for files inside the include path
-            that end in <code>Mainfest.php</code>, <code>Tool.php</code> or
-            <code>Provider.php</code>. Once found, they will be tested (by the
-            <code>load()</code> method of the
-            <code>Zend_Tool_Framework_Loader_Abstract</code>) to determine if
+            that end in <filename>Mainfest.php</filename>, <filename>Tool.php</filename> or
+            <filename>Provider.php</filename>. Once found, they will be tested (by the
+            <methodname>load()</methodname> method of the
+            <classname>Zend_Tool_Framework_Loader_Abstract</classname>) to determine if
             they implement any of the supported interfaces. If they do, an
             instance of the found class is instantiated, and it is appended to
             the proper repository.
@@ -175,8 +175,8 @@ class Zend_Tool_Framework_Loader_IncludePathLoader
 
         <para>
             As you can see, the IncludePath loader will search all include_paths
-            for the files that match the <code>$_filterAcceptFilePattern</code>
-            and NOT match the <code>$_filterDenyDirectoryPattern</code>.
+            for the files that match the <varname>$_filterAcceptFilePattern</varname>
+            and <emphasis>not</emphasis> match the <varname>$_filterDenyDirectoryPattern</varname>.
         </para>
     </sect2>
 
@@ -191,9 +191,9 @@ class Zend_Tool_Framework_Loader_IncludePathLoader
 
         <para>
             To introduce metadata into the manifest repository, all one must do
-            is implement the empty <code>Zend_Tool_Framework_Manifest_Interface</code>, and
-            provide a <code>getMetadata()</code> method which shall return an array of
-            objects that implement <code>Zend_Tool_Framework_Manifest_Metadata</code>.
+            is implement the empty <classname>Zend_Tool_Framework_Manifest_Interface</classname>,
+            and provide a <methodname>getMetadata()</methodname> method which shall return an array
+            of objects that implement <classname>Zend_Tool_Framework_Manifest_Metadata</classname>.
         </para>
 
         <programlisting language="php"><![CDATA[
@@ -205,7 +205,7 @@ interface Zend_Tool_Framework_Manifest_Interface
 
         <para>
             Metadata objects are loaded (by a loader defined below) into the
-            Manifest Repository (<code>Zend_Tool_Framework_Manifest_Repository</code>).
+            Manifest Repository (<classname>Zend_Tool_Framework_Manifest_Repository</classname>).
             Manifests will be processed after all Providers have been found to be
             loaded into the provider repository. This shall allow Manifests to
             create Metadata objects based on what is currently inside the
@@ -215,7 +215,7 @@ interface Zend_Tool_Framework_Manifest_Interface
         <para>
             There are a few different metadata classes that can be used to
             describe metadata. The
-            <code>Zend_Tool_Framework_Manifest_Metadata</code> is the base
+            <classname>Zend_Tool_Framework_Manifest_Metadata</classname> is the base
             metadata object. As you can see by the following code
             snippet, the base metadata class is fairly lightweight and
             abstract in nature:
@@ -240,8 +240,8 @@ class Zend_Tool_Framework_Metadata_Basic
 
         <para>
             There are other built in metadata classes as well for describing
-            more specialized metadata: <code>ActionMetadata</code> and
-            <code>ProviderMetadata</code>. These classes will help you describe
+            more specialized metadata: <classname>ActionMetadata</classname> and
+            <classname>ProviderMetadata</classname>. These classes will help you describe
             in more detail metadata that is specific to either actions or
             providers, and the reference is expected to be a reference to an
             action or a provider respectively. These classes are described in
@@ -279,19 +279,19 @@ class Zend_Tool_Framework_Manifest_ProviderMetadata
         <para>
             'Type' in these classes is used to describe the type of metadata the
             object is responsible for. In the cases of the
-            <code>ActionMetadata</code>, the type would be 'Action', and
-            conversely in the case of the <code>ProviderMetadata</code> the type
+            <classname>ActionMetadata</classname>, the type would be 'Action', and
+            conversely in the case of the <classname>ProviderMetadata</classname> the type
             is 'Provider'. These metadata types will also include additional
             structured information about both the "thing" they are describing as
-            well as the object (the <code>->getReference()</code>) they are
+            well as the object (the <methodname>getReference()</methodname>) they are
             referencing with this new metadata.
         </para>
 
         <para>
             In order to create your own metadata type, all one must do is extend
-            the base <code>Zend_Tool_Framework_Manifest_Metadata</code> class
+            the base <classname>Zend_Tool_Framework_Manifest_Metadata</classname> class
             and return these new metadata objects via a local Manifest
-            class/object. These user based classes will live in the Manifest
+            class or object. These user based classes will live in the Manifest
             Repository
         </para>
 
@@ -345,7 +345,7 @@ class Zend_Tool_Framework_Manifest_Repository
             extremely flexible searching. In order to find a metadata object,
             simply pass in an array of matching constraints via an array. If
             the data is accessible through the Property accessor (the
-            <code>getSomething()</code> methods implemented on the metadata
+            <methodname>getSomething()</methodname> methods implemented on the metadata
             object), then it will be passed back to the user as a "found"
             metadata object.
         </para>
@@ -356,11 +356,11 @@ class Zend_Tool_Framework_Manifest_Repository
 
         <para>
             Clients are the interface which bridges a user or external tool into
-            the <code>Zend_Tool_Framework</code> system. Clients can come in all
-            shapes and sizes: RPC endpoints, Command Line Interface, or
-            even a web interface. Zend_Tool has implemented the command
+            the <classname>Zend_Tool_Framework</classname> system. Clients can come in all
+            shapes and sizes: <acronym>RPC</acronym> endpoints, Command Line Interface, or
+            even a web interface. <classname>Zend_Tool</classname> has implemented the command
             line interface as the default interface for interacting with
-            the <code>Zend_Tool_Framework</code> system.
+            the <classname>Zend_Tool_Framework</classname> system.
         </para>
 
         <para>
@@ -401,7 +401,9 @@ abstract class Zend_Tool_Framework_Client_Abstract
             As you can see, there 1 method is required to fulfill the needs of a
             client (two others suggested), the initialization, prehandling and post handling. For a
             more in depth study of how the command line client works, please see
-            the <ulink url="http://framework.zend.com/svn/framework/standard/branches/release-1.8/library/Zend/Tool/Framework/Client/Console.php">source code</ulink>.
+            the <ulink
+                url="http://framework.zend.com/svn/framework/standard/branches/release-1.8/library/Zend/Tool/Framework/Client/Console.php">source
+                code</ulink>.
         </para>
 
     </sect2>

+ 87 - 81
documentation/manual/en/module_specs/Zend_Tool_Framework-CliTool.xml

@@ -4,13 +4,13 @@
     <title>Using the CLI Tool</title>
 
     <para>
-        The CLI, or command line tool (internally known as the console tool), is
-        currently the primary interface for dispatching <code>Zend_Tool</code>
-        requests. With the CLI tool, developers can issue tooling requests
+        The <acronym>CLI</acronym>, or command line tool (internally known as the console tool),
+        is currently the primary interface for dispatching <classname>Zend_Tool</classname>
+        requests. With the <acronym>CLI</acronym> tool, developers can issue tooling requests
         inside the "command line windows", also commonly known as a "terminal"
         window. This environment is predominant in the *nix environment, but
         also has a common implementation in windows with the
-        <code>cmd.exe</code>, console2 and also with the Cygwin project.
+        <filename>cmd.exe</filename>, console2 and also with the Cygwin project.
     </para>
 
     <sect2 id="zend.tool.framework.clitool.setup-general">
@@ -20,21 +20,22 @@
             To issue tooling requests via the command line client, you first
             need to set up the client so that your system can handle the "zf"
             command. The command line client, for all intents and purposes, is
-            the <code>.sh</code> or <code>.bat</code> file that is provided with
+            the <filename>.sh</filename> or <filename>.bat</filename> file that is provided with
             your Zend Framework distribution. In trunk, it can be found here:
-            <ulink url="http://framework.zend.com/svn/framework/standard/trunk/bin/">http://framework.zend.com/svn/framework/standard/trunk/bin/</ulink>
+            <ulink
+                url="http://framework.zend.com/svn/framework/standard/trunk/bin/">http://framework.zend.com/svn/framework/standard/trunk/bin/</ulink>.
         </para>
 
         <para>
-            As you can see, there are 3 files in the <code>bin/</code>
-            directory: a <code>zf.php</code>, <code>zf.sh</code>, and
-            <code>zf.bat</code>. The <code>zf.sh</code> and the
-            <code>zf.bat</code> are the operating system specific client
-            wrappers: <code>zf.sh</code> for the *nix environment, and <code>zf.bat</code>
-            for the Win32 environment. These client wrappers are responsible
-            for finding the proper <code>php.exe</code>, finding the
-            <code>zf.php</code>, and passing on the client request. The
-            <code>zf.php</code> is the responsible for handling understanding
+            As you can see, there are 3 files in the <filename>/bin/</filename>
+            directory: a <filename>zf.php</filename>, <filename>zf.sh</filename>, and
+            <filename>zf.bat</filename>. The <filename>zf.sh</filename> and the
+            <filename>zf.bat</filename> are the operating system specific client
+            wrappers: <filename>zf.sh</filename> for the *nix environment, and
+            <filename>zf.bat</filename> for the Win32 environment. These client wrappers are
+            responsible for finding the proper <filename>php.exe</filename>, finding the
+            <filename>zf.php</filename>, and passing on the client request. The
+            <filename>zf.php</filename> is the responsible for handling understanding
             your environment, constructing the proper include_path, and passing
             what is provided on the command line to the proper library component
             for dispatching.
@@ -48,24 +49,27 @@
         <orderedlist>
             <listitem>
                 <para>
-                    <code>zf.sh/zf.bat</code> is reachable from your system
-                    path. This is the ability to call <code>zf</code> from
+                    <filename>zf.sh/zf.bat</filename> is reachable from your system
+                    path. This is the ability to call <command>zf</command> from
                     anywhere on your command line, regardless of what your
                     current working directory is.
                 </para>
             </listitem>
             <listitem>
                 <para>
-                    ZendFramework/library is in your <code>include_path</code>.
+                    <filename>ZendFramework/library</filename> is in your
+                    <property>include_path</property>.
                 </para>
             </listitem>
         </orderedlist>
 
-        <para>
-            <emphasis>Note:</emphasis> while the above are the most ideal
-            requirements, you can simply download Zend Framework and expect it
-            to work as <code>./path/to/zf.php</code> some command.
-        </para>
+        <note>
+            <para>
+                Note: while the above are the most ideal
+                requirements, you can simply download Zend Framework and expect it
+                to work as <filename>./path/to/zf.php</filename> some command.
+            </para>
+        </note>
 
     </sect2>
 
@@ -74,8 +78,8 @@
 
         <para>
             The most common setup in the *nix environment, is to copy the
-            <code>zf.sh</code> and <code>zf.php</code> into the same directory
-            as your PHP binary. This can generally be found in one of the
+            <filename>zf.sh</filename> and <filename>zf.php</filename> into the same directory
+            as your <acronym>PHP</acronym> binary. This can generally be found in one of the
             following places:
         </para>
 
@@ -87,22 +91,23 @@
 ]]></programlisting>
 
         <para>
-            To find out the location of your PHP binary, you can execute 'which
-            php' on the command line. This will return the location of the php
-            binary you will be using to run php scripts in this environment.
+            To find out the location of your <acronym>PHP</acronym> binary, you can execute 'which
+            php' on the command line. This will return the location of the <acronym>PHP</acronym>
+            binary you will be using to run <acronym>PHP</acronym> scripts in this environment.
         </para>
 
         <para>
-            The next order of business is to ensure that the Zend Framework
-            library is set up correctly inside of the system PHP
-            <code>include_path</code>. To find out where your
-            <code>include_path</code> is located, you can execute 'php -i' and
-            look for the <code>include_path</code> variable, or more succinctly,
-            execute 'php -i | grep include_path'. Once you have found where
-            your <code>include_path</code> is located (this will generally be
-            something like /usr/lib/php, /usr/share/php, /usr/local/lib/php, or
-            similar), ensure that the contents of the library/ directory are put
-            inside your <code>include_path</code> specified directory.
+            The next order of business is to ensure that Zend Framework
+            library is set up correctly inside of the system <acronym>PHP</acronym>
+            <property>include_path</property>. To find out where your
+            <property>include_path</property> is located, you can execute <command>php -i</command>
+            and look for the <property>include_path</property> variable, or more succinctly,
+            execute <command>php -i | grep include_path</command>. Once you have found where
+            your <property>include_path</property> is located (this will generally be
+            something like <filename>/usr/lib/php</filename>, <filename>/usr/share/php</filename>,
+            <filename>/usr/local/lib/php</filename>, or similar), ensure that the contents of the
+            <filename>/library/</filename> directory are put
+            inside your <property>include_path</property> specified directory.
         </para>
 
         <para>
@@ -127,19 +132,19 @@
         </para>
 
         <para>
-            <emphasis>ALTERNATIVE SETUP</emphasis> involves keeping the Zend
-            Framework download together as is, and creating a link from a PATH
-            location to the <code>zf.sh</code>. What this means is you can
+            <emphasis>Alternative Setup</emphasis> involves keeping the Zend
+            Framework download together as is, and creating a link from a <constant>PATH</constant>
+            location to the <filename>zf.sh</filename>. What this means is you can
             place the contents of the ZendFramework download into a location
-            such as <code>/usr/local/share/ZendFramework</code>, or more locally
-            like <code>/home/username/lib/ZendFramework</code>, and creating a
-            symbolic link to the <code>zf.sh</code>.
+            such as <filename>/usr/local/share/ZendFramework</filename>, or more locally
+            like <filename>/home/username/lib/ZendFramework</filename>, and creating a
+            symbolic link to the <filename>zf.sh</filename>.
         </para>
 
         <para>
-            Assuming you want to put the link inside <code>/usr/local/bin</code>
+            Assuming you want to put the link inside <filename>/usr/local/bin</filename>
             (this could also work for placing the link inside
-            <code>/home/username/bin/</code> for example) you would issue a
+            <filename>/home/username/bin/</filename> for example) you would issue a
             command similar to this: </para>
 
         <programlisting language="sh"><![CDATA[
@@ -161,8 +166,8 @@ ln -s /home/username/lib/ZendFramework/bin/zf.sh /home/username/bin/zf
 
         <para>
             The most common setup in the Windows Win32 environment, is to copy
-            the <code>zf.bat</code> and <code>zf.php</code> into the same
-            directory as your PHP binary. This can generally be found in one of
+            the <filename>zf.bat</filename> and <filename>zf.php</filename> into the same
+            directory as your <acronym>PHP</acronym> binary. This can generally be found in one of
             the following places:
         </para>
 
@@ -173,25 +178,26 @@ C:\WAMP\PHP\bin
 ]]></programlisting>
 
         <para>
-            You should be able to run <code>php.exe</code> on the command line.
+            You should be able to run <filename>php.exe</filename> on the command line.
             If you are not able to, first check the documentation that came with
-            your PHP distribution, or ensure that the path to php.exe is in your
-            windows PATH environment variable.
+            your <acronym>PHP</acronym> distribution, or ensure that the path to
+            <filename>php.exe</filename> is in your
+            Windows <constant>PATH</constant> environment variable.
         </para>
 
         <para>
-            The next order of business is to ensure that the Zend Framework
-            library is set up correctly inside of the system PHP
-            <code>include_path</code>. To find out where your
-            <code>include_path</code> is located, you can type 'php -i' and look
-            for the <code>include_path</code> variable, or more succinctly
-            execute 'php -i | grep include_path' if you have Cygwin setup with
+            The next order of business is to ensure that Zend Framework
+            library is set up correctly inside of the system <acronym>PHP</acronym>
+            <property>include_path</property>. To find out where your
+            <property>include_path</property> is located, you can type <command>php -i</command> and
+            look for the <property>include_path</property> variable, or more succinctly
+            execute <command>php -i | grep include_path</command> if you have Cygwin setup with
             grep available. Once you have found where your
-            <code>include_path</code> is located (this will generally be
-            something like <code>C:\PHP\pear</code>, <code>C:\PHP\share</code>,
-            <code>C:\Program Files\ZendServer\share</code> or similar), ensure
+            <property>include_path</property> is located (this will generally be
+            something like <filename>C:\PHP\pear</filename>, <filename>C:\PHP\share</filename>,
+            <filename>C:\Program%20Files\ZendServer\share</filename> or similar), ensure
             that the contents of the library/ directory are put inside your
-            <code>include_path</code> specified directory.
+            <property>include_path</property> specified directory.
         </para>
 
         <para>
@@ -216,15 +222,15 @@ C:\WAMP\PHP\bin
         </para>
 
         <para>
-            <emphasis>ALTERNATIVE SETUP</emphasis> involves keeping the Zend
+            <emphasis>Alternative Setup</emphasis> involves keeping the Zend
             Framework download together as is, and altering both your system
-            PATH as well as the <code>php.ini</code> file. In your user's
-            environment, make sure to add
-            <code>C:\Path\To\ZendFramework\bin</code>, so that your
-            <code>zf.bat</code> file is executable. Also, alter the
-            <code>php.ini</code> file to ensure that
-            <code>C:\Path\To\ZendFramework\library</code> is in your
-            <code>include_path</code>.
+            <constant>PATH</constant> as well as the <filename>php.ini</filename> file.
+            In your user's environment, make sure to add
+            <filename>C:\Path\To\ZendFramework\bin</filename>, so that your
+            <filename>zf.bat</filename> file is executable. Also, alter the
+            <filename>php.ini</filename> file to ensure that
+            <filename>C:\Path\To\ZendFramework\library</filename> is in your
+            <property>include_path</property>.
         </para>
 
     </sect2>
@@ -233,25 +239,25 @@ C:\WAMP\PHP\bin
         <title>Other Setup Considerations</title>
 
         <para>
-            If for some reason you do not want the Zend Framework library inside
-            your <code>include_path</code>, there is another option. There are
-            two special environment variables that <code>zf.php</code> will
+            If for some reason you do not want Zend Framework library inside
+            your <property>include_path</property>, there is another option. There are
+            two special environment variables that <filename>zf.php</filename> will
             utilize to determine the location of your Zend Framework
             installation.
         </para>
 
         <para>
-            The first is <code>ZEND_TOOL_INCLUDE_PATH_PREPEND</code>, which will
+            The first is <constant>ZEND_TOOL_INCLUDE_PATH_PREPEND</constant>, which will
             prepend the value of this environment variable to the system
-            (<code>php.ini</code>) <code>include_path</code> before loading the
+            (<filename>php.ini</filename>) <property>include_path</property> before loading the
             client.
         </para>
 
         <para>
             Alternatively, you might want to use
-            <code>ZEND_TOOL_INCLUDE_PATH</code> to completely
-            <emphasis>replace</emphasis> the system <code>include_path</code>
-            for one that makes sense specifically for the <code>zf</code>
+            <constant>ZEND_TOOL_INCLUDE_PATH</constant> to completely
+            <emphasis>replace</emphasis> the system <property>include_path</property>
+            for one that makes sense specifically for the <command>zf</command>
             command line tool.
         </para>
     </sect2>
@@ -261,8 +267,8 @@ C:\WAMP\PHP\bin
 
         <para>
             At this point, you should be set up to start initiating some more
-            "interesting" commands. To get going, you can issue the <code>zf
-                --help</code> command to see what is available to you.
+            "interesting" commands. To get going, you can issue the
+            <command>zf --help</command> command to see what is available to you.
         </para>
 
         <para>
@@ -271,8 +277,8 @@ C:\WAMP\PHP\bin
         </para>
 
         <para>
-            Continue on to the <code>Zend_Tool_Project</code> "Create Project"
-            section to understand how to use the <code>zf</code> script for
+            Continue on to the <classname>Zend_Tool_Project</classname> "Create Project"
+            section to understand how to use the <command>zf</command> script for
             project creation.
         </para>
     </sect2>

+ 7 - 7
documentation/manual/en/module_specs/Zend_Tool_Framework-Introduction.xml

@@ -7,11 +7,11 @@
         <classname>Zend_Tool_Framework</classname> is a framework for exposing common
         functionalities such as the creation of project scaffolds, code
         generation, search index generation, and much more. Functionality may be
-        written and exposed via PHP classes dropped into the PHP
-        <code>include_path</code>, providing incredible flexibility of
-        implementation. The functionality may then be consumed by writing
+        written and exposed via <acronym>PHP</acronym> classes dropped into the
+        <acronym>PHP</acronym> <property>include_path</property>, providing incredible
+        flexibility of implementation. The functionality may then be consumed by writing
         implementation and/or protocol-specific clients -- such as console
-        clients, XML-RPC, SOAP, and much more.
+        clients, <acronym>XML-RPC</acronym>, <acronym>SOAP</acronym>, and much more.
     </para>
 
     <para>
@@ -21,7 +21,7 @@
     <itemizedlist>
         <listitem>
             <para>
-                <code>Common interfaces and abstracts</code> that allow
+                <emphasis>Common interfaces and abstracts</emphasis> that allow
                 developers to create functionality and capabilities that are
                 dispatchable by tooling clients.
             </para>
@@ -32,7 +32,7 @@
                 <emphasis>Base client functionality</emphasis> and a concrete
                 console implementation that connect external tools and
                 interfaces to the <classname>Zend_Tool_Framework</classname>. The Console
-                client may be used in CLI environments such as unix shells and
+                client may be used in <acronym>CLI</acronym> environments such as unix shells and
                 the Windows console.
             </para>
         </listitem>
@@ -90,7 +90,7 @@
 
         <listitem><para>
             <emphasis>Console Client / Command Line Interface /
-            zf.php</emphasis> - The tooling client for the command line.
+            <filename>zf.php</filename></emphasis> - The tooling client for the command line.
         </para></listitem>
 
         <listitem><para>

+ 8 - 8
documentation/manual/en/module_specs/Zend_Tool_Framework-SystemProviders.xml

@@ -5,9 +5,9 @@
 
     <para>
         In addition to the more useful project based providers that come shipped
-        with <code>Zend_Tool_Project</code>, there are also some more basic, but
+        with <classname>Zend_Tool_Project</classname>, there are also some more basic, but
         interesting providers that come built into
-        <code>Zend_Tool_Framework</code>. Some of these exist for the purpose
+        <classname>Zend_Tool_Framework</classname>. Some of these exist for the purpose
         of providing a means via the command line to extract information, such
         as the version, while others are intended to aid the developer when
         creating additional providers.
@@ -18,12 +18,12 @@
 
         <para>
             The Version provider is included so that you may determine which
-            version of the framework that the <code>zf</code> or
-            <code>Zend_Tool</code> is currently set to work with.
+            version of the framework that the <command>zf</command> or
+            <classname>Zend_Tool</classname> is currently set to work with.
         </para>
 
         <para>
-            Through the command line, simply run <code>zf show version</code>.
+            Through the command line, simply run <command>zf show version</command>.
         </para>
 
     </sect2>
@@ -34,8 +34,8 @@
         <para>
             The Manifest provider is included so that you may determine what
             kind of "manifest" information is available during the
-            <code>Zend_Tool</code> runtime. Manifest data is information that
-            is attached to specific objects during <code>Zend_Tool</code>'s
+            <classname>Zend_Tool</classname> runtime. Manifest data is information that
+            is attached to specific objects during <classname>Zend_Tool</classname>'s
             runtime. Inside the manifest you will find the console specific
             namings that you are expected to use when calling certain commands.
             Data found in the manifest can be used by any provider or client on
@@ -43,7 +43,7 @@
         </para>
 
         <para>
-            Through the command line, simply run <code>zf show manifest</code>.
+            Through the command line, simply run <command>zf show manifest</command>.
         </para>
     </sect2>
 </sect1>

+ 8 - 8
documentation/manual/en/module_specs/Zend_Tool_Framework-WritingProviders.xml

@@ -7,7 +7,7 @@
         In general, a provider, on its own, is nothing more than the shell for a
         developer to bundle up some capabilities they wish to dispatch with the
         command line (or other) clients. It is an analogue to what a
-        "controller" is inside of your MVC application.
+        "controller" is inside of your <acronym>MVC</acronym> application.
     </para>
 
     <sect2 id="zend.tool.framework.writing-providers.basic">
@@ -17,10 +17,10 @@
             As an 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 component is called <code>My_Component</code>, he would
-            create a class named <code>My_Component_HelloProvider</code> in a
-            file named <code>HelloProvider.php</code> somewhere on the
-            <code>include_path</code>. This class would implement
+            Assuming the component is called <classname>My_Component</classname>, he would
+            create a class named <classname>My_Component_HelloProvider</classname> in a
+            file named <filename>HelloProvider.php</filename> somewhere on the
+            <property>include_path</property>. This class would implement
             <classname>Zend_Tool_Framework_Provider_Interface</classname>, and the body of
             this file would only have to look like the following:
         </para>
@@ -81,11 +81,11 @@ class My_Component_HelloProvider
 ]]></programlisting>
 
         <para>
-            The above example can then be called via the command line <code>zf
-                say hello Joe</code>. "Joe" will be supplied to the provider as
+            The above example can then be called via the command line
+            <command>zf say hello Joe</command>. "Joe" will be supplied to the provider as
             a parameter of the method call. Also note, as you see that the
             parameter is optional, that means it is also optional on the command
-            line, so that <code>zf say hello</code> will still work, and default
+            line, so that <command>zf say hello</command> will still work, and default
             to the name "Ralph".
         </para>