[DOCUMENTATION] English:

 - fix compilation error
 - remove tabs, endline spaces

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

documentation/manual/en/module_specs/Zend_Db_Adapter.xml

@@ -313,10 +313,10 @@ $db = Zend_Db::factory($config->database);
                         on the RDBMS server.
                     </para>
                 </listitem>
-				<listitem>
+                <listitem>
                     <para>
                         <emphasis>charset</emphasis>:
-						specify the charset used for the connection.
+                        specify the charset used for the connection.
                     </para>
                 </listitem>
                 <listitem>

documentation/manual/en/module_specs/Zend_Http_Client-Migration.xml

@@ -5,17 +5,17 @@
     <title>Migrating from previous versions</title>
 
     <para>
-        While the external API of <classname>Zend_Http_Client</classname> has remained 
+        While the external API of <classname>Zend_Http_Client</classname> has remained
         consistent throughout the 1.x brach of Zend Framework, some changes were introduced
         to the internal structure of <classname>Zend_Http_Client</classname> and its related
-        classes. 
+        classes.
     </para>
-    
+
     <para>
         These changes should have no affect on code using <classname>Zend_Http_Client</classname>
         - but may have an effect on PHP classes overloading or extending it. If your application
         subclasses <classname>Zend_Http_Client</classname>, it is highly recommended to review
-        the following changes before upgrading Zend Framework.   
+        the following changes before upgrading Zend Framework.
     </para>
 
     <sect2 id="zend.http.client.migration.tozf19">
@@ -26,10 +26,10 @@
             <para>
                 In version 1.9 of Zend Framework, there has been a change in the way
                 <classname>Zend_Http_Client</classname> internally stores information about
-                files to be uploaded, set using the <classname>Zend_Http_Client::setFileUpload()</classname> 
+                files to be uploaded, set using the <classname>Zend_Http_Client::setFileUpload()</classname>
                 method.
             </para>
-            
+
             <para>
                 This change was introduced in order to allow multiple files to be uploaded
                 with the same form name, as an array of files. More information about this issue
@@ -38,7 +38,7 @@
 
             <example id="zend.http.client.migration.tozf19.fileuploadsarray.example">
                 <title>Internal storage of uploaded file information</title>
-                
+
                 <programlisting language="php"><![CDATA[
 // Upload two files with the same form element name, as an array
 $client = new Zend_Http_Client();
@@ -67,32 +67,32 @@ $client->setFileUpload('file2.txt', 'userfile[]', 'some other data', 'applicatio
 // );
 ]]></programlisting>
             </example>
-            
+
             <para>
                 As you can see this change permits the usage of the same form element name with
                 more than one file - however, it introduces a subtle backwards-compatibility change
-                and as such should be noted. 
+                and as such should be noted.
             </para>
         </sect3>
-        
+
         <sect3 id="zend.http.client.migration.tozf19.getparamsrecursize">
             <title>Deprecation of Zend_Http_Client::_getParametersRecursive()</title>
 
             <para>
                 Starting from version 1.9, the protected method <classname>_getParametersRecursive()</classname>
-                is no longer used by <classname>Zend_Http_Client</classname> and is deprecated. 
-                Using it will cause an E_NOTICE message to be emitted by PHP. 
+                is no longer used by <classname>Zend_Http_Client</classname> and is deprecated.
+                Using it will cause an E_NOTICE message to be emitted by PHP.
             </para>
-            
+
             <para>
                 If you subclass <classname>Zend_Http_Client</classname> and call this method, you
                 should look into using the <classname>Zend_Http_Client::_flattenParametersArray()</classname>
-                static method instead. 
+                static method instead.
             </para>
-            
+
             <para>
                 Again, since this <classname>_getParametersRecursive</classname> is a protected method,
-                this change will only affect users who subclass <classname>Zend_Http_Client</classname>. 
+                this change will only affect users who subclass <classname>Zend_Http_Client</classname>.
             </para>
         </sect3>
     </sect2>

documentation/manual/en/module_specs/Zend_Test-PHPUnit-Db-Adapter.xml

@@ -4,18 +4,18 @@
     <title>Using the Database Testing Adapter</title>
 
     <para>
-        There are times when you don't want to test parts of your application with a real database, 
+        There are times when you don't want to test parts of your application with a real database,
         but are forced to because of coupling. The <classname>Zend_Test_DbAdapter</classname> offers
-        a convenient way to use a implementation of <classname>Zend_Db_Adapter_Abstract</classname> 
-        without having to open a database connection. Furthermore this Adapter is very easy to mock 
+        a convenient way to use a implementation of <classname>Zend_Db_Adapter_Abstract</classname>
+        without having to open a database connection. Furthermore this Adapter is very easy to mock
         from within your PHPUnit testsuite, since it requires no constructor arguments.
     </para>
 
     <para>
         The Test Adapter acts as a stack for various database results. Its order of results have to
-        be userland implemented, which might be a tedious task for tests that call many different 
-        database queries, but its just the right helper for tests where only a handful of queries 
-        are executed and you know the exact order of the results that have to be returned to your 
+        be userland implemented, which might be a tedious task for tests that call many different
+        database queries, but its just the right helper for tests where only a handful of queries
+        are executed and you know the exact order of the results that have to be returned to your
         userland code.
     </para>
 
@@ -37,18 +37,18 @@ $rs = $adapter->query('SELECT ...'); // Returns Statement 1
 ]]></programlisting>
 
     <para>
-        Behaviour of any real database adapter is simulated as much as possible such that methods 
-        like <methodname>fetchAll()</methodname>, <methodname>fetchObject()</methodname>, 
+        Behaviour of any real database adapter is simulated as much as possible such that methods
+        like <methodname>fetchAll()</methodname>, <methodname>fetchObject()</methodname>,
         <methodname>fetchColumn</methodname> and more are working for the test adapter.
     </para>
 
     <para>
-        You can also put INSERT, UPDATE and DELETE statement onto the result stack, these however 
-        only return a statement which allows to specifiy the result of 
+        You can also put INSERT, UPDATE and DELETE statement onto the result stack, these however
+        only return a statement which allows to specifiy the result of
         <methodname>$stmt->rowCount()</methodname>.
     </para>
 
-    <programlisting role="php"><![CDATA[
+    <programlisting language="php"><![CDATA[
 $adapter = new Zend_Test_DbAdapter();
 $adapter->appendStatementToStack(Zend_Test_DbStatement::createInsertStatement(1));
 $adapter->appendStatementToStack(Zend_Test_DbStatement::createUpdateStatement(2));
@@ -56,14 +56,14 @@ $adapter->appendStatementToStack(Zend_Test_DbStatement::createDeleteStatement(10
 ]]></programlisting>
 
     <para>
-        The test adapter never checks if the query specified is really of the type SELECT, DELETE, 
-        INSERT or UPDATE which is returned next from the stack. The correct order of returning the 
+        The test adapter never checks if the query specified is really of the type SELECT, DELETE,
+        INSERT or UPDATE which is returned next from the stack. The correct order of returning the
         data has to be implemented by the user of the test adapter.
     </para>
 
     <para>
-        The Test adapter also specifies methods to simulate the use of the methods 
-        <methodname>listTables()</methodname>, <methodname>describeTables()</methodname> and 
+        The Test adapter also specifies methods to simulate the use of the methods
+        <methodname>listTables()</methodname>, <methodname>describeTables()</methodname> and
         <methodname>lastInsertId()</methodname>.
     </para>
 </sect2>

documentation/manual/en/module_specs/Zend_Test-PHPUnit-Db-Quickstart.xml

@@ -5,23 +5,23 @@
 
     <sect3 id="zend.test.phpunit.db.quickstart.testcase">
         <title>Setup a Database TestCase</title>
-        
+
         <para>
-            We are now writting some database tests for the Bug Database example in the 
-            <classname>Zend_Db_Table</classname> documentation. First we begin to test that 
-            inserting a new bug is actually saved in the database correctly. First we have to 
-            setup a test-class that extends 
+            We are now writting some database tests for the Bug Database example in the
+            <classname>Zend_Db_Table</classname> documentation. First we begin to test that
+            inserting a new bug is actually saved in the database correctly. First we have to
+            setup a test-class that extends
             <classname>Zend_Test_PHPUnit_DatabaseTestCase</classname>. This class extends the
-            PHPUnit Database Extension, which in turn extends the basic 
+            PHPUnit Database Extension, which in turn extends the basic
             <classname>PHPUnit_Framework_TestCase</classname>. A database testcase contains two
-            abstract methods that have to be implemented, one for the database connection and 
+            abstract methods that have to be implemented, one for the database connection and
             one for the initial dataset that should be used as seed or fixture.
         </para>
 
         <note>
             <para>
                 You should be familiar with the PHPUnit Database extension to follow this quickstart
-                easily. Although all the concepts are explained in this documentation it may be 
+                easily. Although all the concepts are explained in this documentation it may be
                 helpful to read the PHPUnit documentation first.
             </para>
         </note>
@@ -30,7 +30,7 @@
 class BugsTest extends Zend_Test_PHPUnit_DatabaseTestCase
 {
     private $_connectionMock;
-    
+
     /**
      * Returns the test database connection.
      *
@@ -47,7 +47,7 @@ class BugsTest extends Zend_Test_PHPUnit_DatabaseTestCase
         }
         return $this->_connectionMock;
     }
-    
+
     /**
      * @return PHPUnit_Extensions_Database_DataSet_IDataSet
      */
@@ -61,7 +61,7 @@ class BugsTest extends Zend_Test_PHPUnit_DatabaseTestCase
 ]]></programlisting>
 
         <para>
-            Here we create the database connection and seed some data into the database. Some 
+            Here we create the database connection and seed some data into the database. Some
             important details should be noted on this code:
         </para>
 
@@ -69,35 +69,35 @@ class BugsTest extends Zend_Test_PHPUnit_DatabaseTestCase
             <listitem>
                 <para>
                     You cannot directly return a <classname>Zend_Db_Adapter_Abstract</classname>
-                    from the <methodname>getConnection()</methodname> method, but a PHPUnit 
-                    specific wrapper which is generated with the 
+                    from the <methodname>getConnection()</methodname> method, but a PHPUnit
+                    specific wrapper which is generated with the
                     <methodname>createZendDbConnection()</methodname> method.
                 </para>
             </listitem>
 
             <listitem>
                 <para>
-                    The database schema (tables and database) is not re-created on every 
-                    testrun. The database and tables have to be created manually before running 
+                    The database schema (tables and database) is not re-created on every
+                    testrun. The database and tables have to be created manually before running
                     the tests.
                 </para>
             </listitem>
 
             <listitem>
                 <para>
-                    Database tests by default truncate the data during 
-                    <methodname>setUp()</methodname> and then insert the seed data which is 
+                    Database tests by default truncate the data during
+                    <methodname>setUp()</methodname> and then insert the seed data which is
                     returned from the <methodname>getDataSet()</methodname> method.
                 </para>
             </listitem>
 
             <listitem>
                 <para>
-                    DataSets have to implement the interface 
-                    <classname>PHPUnit_Extensions_Database_DataSet_IDataSet</classname>.  
-                    There is a wide range of XML and YAML configuration file types included in 
-                    PHPUnit which allows to specifiy how the tables and datasets should look 
-                    like and you should look into the PHPUnit documentation to get the latest 
+                    DataSets have to implement the interface
+                    <classname>PHPUnit_Extensions_Database_DataSet_IDataSet</classname>.
+                    There is a wide range of XML and YAML configuration file types included in
+                    PHPUnit which allows to specifiy how the tables and datasets should look
+                    like and you should look into the PHPUnit documentation to get the latest
                     information on these dataset specifications.
                 </para>
             </listitem>
@@ -115,13 +115,13 @@ class BugsTest extends Zend_Test_PHPUnit_DatabaseTestCase
         <programlisting language="xml"><![CDATA[
 <?xml version="1.0" encoding="UTF-8" ?>
 <dataset>
-    <zfbugs bug_id="1" bug_description="system needs electricity to run" 
-        bug_status="NEW" created_on="2007-04-01 00:00:00" 
-        updated_on="2007-04-01 00:00:00" reported_by="goofy" 
+    <zfbugs bug_id="1" bug_description="system needs electricity to run"
+        bug_status="NEW" created_on="2007-04-01 00:00:00"
+        updated_on="2007-04-01 00:00:00" reported_by="goofy"
         assigned_to="mmouse" verified_by="dduck" />
-    <zfbugs bug_id="2" bug_description="Implement Do What I Mean function" 
-        bug_status="VERIFIED" created_on="2007-04-02 00:00:00" 
-        updated_on="2007-04-02 00:00:00" reported_by="goofy" 
+    <zfbugs bug_id="2" bug_description="Implement Do What I Mean function"
+        bug_status="VERIFIED" created_on="2007-04-02 00:00:00"
+        updated_on="2007-04-02 00:00:00" reported_by="goofy"
         assigned_to="mmouse" verified_by="dduck" />
     <zfbugs bug_id="3" bug_description="Where are my keys?" bug_status="FIXED"
         created_on="2007-04-03 00:00:00" updated_on="2007-04-03 00:00:00"
@@ -133,7 +133,7 @@ class BugsTest extends Zend_Test_PHPUnit_DatabaseTestCase
 ]]></programlisting>
 
         <para>
-            We will work with this four entries in the database table "zfbugs" in the next 
+            We will work with this four entries in the database table "zfbugs" in the next
             examples. The required MySQL schema for this example is:
         </para>
 
@@ -156,8 +156,8 @@ PRIMARY KEY  (`bug_id`)
         <title>A few initial database tests</title>
 
         <para>
-            Now that we have implemented the two required abstract methods of the 
-            <classname>Zend_Test_PHPUnit_DatabaseTestCase</classname> and specified the seed 
+            Now that we have implemented the two required abstract methods of the
+            <classname>Zend_Test_PHPUnit_DatabaseTestCase</classname> and specified the seed
             database content, which will be re-created for each new test, we can go about to make
             our first assertion. This will be a test to insert a new bug.
         </para>
@@ -168,7 +168,7 @@ class BugsTest extends Zend_Test_PHPUnit_DatabaseTestCase
     public function testBugInsertedIntoDatabase()
     {
         $bugsTable = new Bugs();
-    
+
         $data = array(
             'created_on'      => '2007-03-22 00:00:00',
             'updated_on'      => '2007-03-22 00:00:00',
@@ -178,12 +178,12 @@ class BugsTest extends Zend_Test_PHPUnit_DatabaseTestCase
             'verified_by'     => 'garfield',
             'assigned_to'     => 'mmouse',
         );
-    
+
         $bugsTable->insert($data);
-    
+
         $ds = new Zend_Test_PHPUnit_Db_DataSet_QueryDataSet($this->getConnection());
         $ds->addTable('zfbugs', 'SELECT * FROM zfbugs');
-    
+
         $this->assertDataSetsEqual(
             $this->createFlatXmlDataSet(dirname(__FILE__)."/_files/bugsInsertIntoAssertion.xml"),
             $ds
@@ -195,13 +195,13 @@ class BugsTest extends Zend_Test_PHPUnit_DatabaseTestCase
         <para>
             Now up to the <methodname>$bugsTable->insert($data);</methodname> everything looks
             familiar.  The lines after that contain the assertion methodname. We want to verify
-            that after inserting the new bug the database has been updated correctly with the 
-            given data.  For this we create a 
-            <classname>Zend_Test_PHPUnit_Db_DataSet_QueryDataSet</classname> instance and give 
-            it a database connection. We will then tell this dataset that it contains a table 
-            "zfbugs" which is given by an SQL statement. This current/actual state of the 
-            database is compared to the expected database state which is contained in another 
-            XML file "bugsInsertIntoAssertions.xml". This XML file is a slight deviation from 
+            that after inserting the new bug the database has been updated correctly with the
+            given data.  For this we create a
+            <classname>Zend_Test_PHPUnit_Db_DataSet_QueryDataSet</classname> instance and give
+            it a database connection. We will then tell this dataset that it contains a table
+            "zfbugs" which is given by an SQL statement. This current/actual state of the
+            database is compared to the expected database state which is contained in another
+            XML file "bugsInsertIntoAssertions.xml". This XML file is a slight deviation from
             the one given above and contains another row with the expected data:
         </para>
 
@@ -216,9 +216,9 @@ class BugsTest extends Zend_Test_PHPUnit_DatabaseTestCase
 ]]></programlisting>
 
         <para>
-            There are other ways to assert that the current database state equals an expected 
+            There are other ways to assert that the current database state equals an expected
             state.  The "Bugs" table in the example already nows a lot about its inner state, so
-            why not use this to our advantage? The next example will assert that deleting from 
+            why not use this to our advantage? The next example will assert that deleting from
             the database is possible:
         </para>
 
@@ -228,14 +228,14 @@ class BugsTest extends Zend_Test_PHPUnit_DatabaseTestCase
     public function testBugDelete()
     {
         $bugsTable = new Bugs();
-    
+
         $bugsTable->delete(
             $bugsTable->getAdapter()->quoteInto("bug_id = ?", 4)
         );
-    
+
         $ds = new Zend_Test_PHPUnit_Db_DataSet_DbTableDataSet();
         $ds->addTable($bugsTable);
-    
+
         $this->assertDataSetsEqual(
             $this->createFlatXmlDataSet(dirname(__FILE__)."/_files/bugsDeleteAssertion.xml"),
             $ds
@@ -247,49 +247,49 @@ class BugsTest extends Zend_Test_PHPUnit_DatabaseTestCase
         <para>
             We have created a <classname>Zend_Test_PHPUnit_Db_DataSet_DbTableDataSet</classname>
             dataset here, which takes any <classname>Zend_Db_Table_Abstract</classname> instance
-            and adds it to the dataset with its table name, in this example "zfbugs". You could 
-            add several tables more if you wanted using the method 
+            and adds it to the dataset with its table name, in this example "zfbugs". You could
+            add several tables more if you wanted using the method
             <methodname>addTable()</methodname> if you want to check for expected database state
             in more than one table.
         </para>
 
         <para>
-            Here we only have one table and check against an expected database state in 
+            Here we only have one table and check against an expected database state in
             "bugsDeleteAssertion.xml" which is the original seed dataset without the row with id
             4.
         </para>
 
         <para>
             Since we have only checked that two specific tables (not datasets) are equal in the
-            previous examples we should also look at how to assert that two tables are equal. 
+            previous examples we should also look at how to assert that two tables are equal.
             Therefore we will add another test to our TestCase which verifies updating behaviour
             of a dataset.
         </para>
 
-        <programlisting lanugage="php"><![CDATA[
+        <programlisting language="php"><![CDATA[
 class BugsTest extends Zend_Test_PHPUnit_DatabaseTestCase
 {
     public function testBugUpdate()
     {
         $bugsTable = new Bugs();
-    
+
         $data = array(
             'updated_on'      => '2007-05-23',
             'bug_status'      => 'FIXED'
         );
-    
+
         $where = $bugsTable->getAdapter()->quoteInto('bug_id = ?', 1);
-    
+
         $bugsTable->update($data, $where);
-    
+
         $rowset = $bugsTable->fetchAll();
-    
+
         $ds        = new Zend_Test_PHPUnit_Db_DataSet_DbRowset($rowset);
         $assertion = $this->createFlatXmlDataSet(
             dirname(__FILE__) . '/_files/bugsUpdateAssertion.xml'
         );
         $expectedRowsets = $assertion->getTable('zfbugs');
-    
+
         $this->assertTablesEqual(
             $expectedRowsets, $ds
         );
@@ -298,11 +298,11 @@ class BugsTest extends Zend_Test_PHPUnit_DatabaseTestCase
 ]]></programlisting>
 
         <para>
-            Here we create the current database state from a 
-            <classname>Zend_Db_Table_Rowset_Abstract</classname> instance in conjunction with 
+            Here we create the current database state from a
+            <classname>Zend_Db_Table_Rowset_Abstract</classname> instance in conjunction with
             the <classname>Zend_Test_PHPUnit_Db_DataSet_DbRowset($rowset)</classname> instance
-            which creates an internal data-representation of the rowset.  This can again be 
-            compared against another data-table by using the 
+            which creates an internal data-representation of the rowset.  This can again be
+            compared against another data-table by using the
             <methodname>$this->assertTablesEqual()</methodname> assertion.
         </para>
     </sect3>

documentation/manual/en/module_specs/Zend_Test-PHPUnit-Db-Testing.xml

@@ -4,9 +4,9 @@
     <title>Usage, API and Extensions Points</title>
 
     <para>
-        The Quickstart already gave a good introduction on how database testing can be done using 
-        PHPUnit and the Zend Framework. This section gives an overview over the API that the 
-        <classname>Zend_Test_PHPUnit_Db</classname> component comes with and how it works 
+        The Quickstart already gave a good introduction on how database testing can be done using
+        PHPUnit and the Zend Framework. This section gives an overview over the API that the
+        <classname>Zend_Test_PHPUnit_Db</classname> component comes with and how it works
         internally.
     </para>
 
@@ -14,14 +14,14 @@
         <title>Some Remarks on Database Testing</title>
 
         <para>
-            Just as the Controller TestCase is testing an application at an integration level, the 
-            Database TestCase is an integration testing method. Its using several different 
+            Just as the Controller TestCase is testing an application at an integration level, the
+            Database TestCase is an integration testing method. Its using several different
             application layers for testing purposes and therefore should be consumed with caution.
         </para>
 
         <para>
             It should be noted that testing domain and business logic with integration tests such
-            as Zend Framework's Controller and Database TestCases is a bad practice. The purpose of 
+            as Zend Framework's Controller and Database TestCases is a bad practice. The purpose of
             an Integration test is to check that several parts of an application work smoothly when
             wired together. These integration tests do not replace the need for a set of unit tests
             that test the domain and business logic at a much smaller level, the isolated class.
@@ -32,18 +32,18 @@
         <title>The Zend_Test_PHPUnit_DatabaseTestCase class</title>
 
         <para>
-            The <classname>Zend_Test_PHPUnit_DatabaseTestCase</classname> class derives from the 
-            <classname>PHPUnit_Extensions_Database_TestCase</classname> which allows to setup tests 
-            with a fresh database fixture on each run easily. The Zend implementation offers some 
-            additional convenience features over the PHPUnit Database extension when it comes to 
-            using <classname>Zend_Db</classname> resources inside your tests. The workflow of a 
+            The <classname>Zend_Test_PHPUnit_DatabaseTestCase</classname> class derives from the
+            <classname>PHPUnit_Extensions_Database_TestCase</classname> which allows to setup tests
+            with a fresh database fixture on each run easily. The Zend implementation offers some
+            additional convenience features over the PHPUnit Database extension when it comes to
+            using <classname>Zend_Db</classname> resources inside your tests. The workflow of a
             database test-case can be described as follows.
         </para>
 
         <orderedlist>
             <listitem>
                 <para>
-                    For each test PHPUnit creates a new instance of the TestCase and calls the 
+                    For each test PHPUnit creates a new instance of the TestCase and calls the
                     <methodname>setUp()</methodname> method.
                 </para>
             </listitem>
@@ -57,31 +57,31 @@
 
             <listitem>
                 <para>
-                    The database tester collects the information on the database connection and 
-                    initial dataset from <methodname>getConnection()</methodname> and 
-                    <methodname>getDataSet()</methodname> which are both abstract methods and have 
+                    The database tester collects the information on the database connection and
+                    initial dataset from <methodname>getConnection()</methodname> and
+                    <methodname>getDataSet()</methodname> which are both abstract methods and have
                     to be implemented by any Database Testcase.
                 </para>
             </listitem>
 
             <listitem>
                 <para>
-                    By default the database tester truncates the tables specified in the given 
+                    By default the database tester truncates the tables specified in the given
                     dataset, and then inserts the data given as initial fixture.
                 </para>
             </listitem>
 
             <listitem>
                 <para>
-                    When the database tester has finished setting up the database, PHPUnit runs the 
+                    When the database tester has finished setting up the database, PHPUnit runs the
                     test.
                 </para>
             </listitem>
 
             <listitem>
                 <para>
-                    After running the test, <methodname>tearDown()</methodname> is called. Because 
-                    the database is wiped in <methodname>setUp()</methodname> before inserting the 
+                    After running the test, <methodname>tearDown()</methodname> is called. Because
+                    the database is wiped in <methodname>setUp()</methodname> before inserting the
                     required initial fixture, no actions are executed by the database tester at this
                     stage.
                 </para>
@@ -97,7 +97,7 @@
 
         <para>
             The <classname>Zend_Test_PHPUnit_DatabaseTestCase</classname> class has some convenience
-            functions that can help writing tests that interact with the database and the database 
+            functions that can help writing tests that interact with the database and the database
             testing extension.
         </para>
 
@@ -105,8 +105,8 @@
             <title>Zend_Test_PHPUnit_DatabaseTestCase API Methods</title>
 
             <para>
-                This lists only the new methods compared to the 
-                <classname>PHPUnit_Extensions_Database_TestCase</classname>, whose <ulink 
+                This lists only the new methods compared to the
+                <classname>PHPUnit_Extensions_Database_TestCase</classname>, whose <ulink
                     url="http://www.phpunit.de/manual/current/en/database.html">API is documented in
                 the PHPUnit Documentation</ulink>.
             </para>
@@ -125,11 +125,11 @@
                             <methodname>createZendDbConnection(Zend_Db_Adapter_Abstract $connection,
                                 $schema)</methodname>
                         </entry>
-                        
+
                         <entry>
-                            Create a PHPUnit Database Extension compatible Connection instance from 
+                            Create a PHPUnit Database Extension compatible Connection instance from
                             a <classname>Zend_Db_Adapter_Abstract</classname> instance.  This method
-                            should be used in for testcase setup when implementing the abstract 
+                            should be used in for testcase setup when implementing the abstract
                             <methodname>getConnection()</methodname> method of the database testcase.
                         </entry>
                     </row>
@@ -138,7 +138,7 @@
                         <entry><methodname>getAdapter()</methodname></entry>
 
                         <entry>
-                            Convenience method to access the underlying 
+                            Convenience method to access the underlying
                             <classname>Zend_Db_Adapter_Abstract</classname> instance which is nested
                             inside the PHPUnit database connection created with
                             <methodname>getConnection()</methodname>.
@@ -147,27 +147,27 @@
 
                     <row>
                         <entry>
-                            <methodname>createDbRowset(Zend_Db_Table_Rowset_Abstract $rowset, 
+                            <methodname>createDbRowset(Zend_Db_Table_Rowset_Abstract $rowset,
                                 $tableName = null)</methodname>
                         </entry>
 
                         <entry>
-                            Create a DataTable Object that is filled with the data from a given 
+                            Create a DataTable Object that is filled with the data from a given
                             <classname>Zend_Db_Table_Rowset_Abstract</classname> instance. The table
-                            the rowset is connected to is chosen when <code>$tableName</code> is 
+                            the rowset is connected to is chosen when <code>$tableName</code> is
                             null.
                         </entry>
                     </row>
 
                     <row>
                         <entry>
-                            <methodname>createDbTable(Zend_Db_Table_Abstract $table, $where = null, 
+                            <methodname>createDbTable(Zend_Db_Table_Abstract $table, $where = null,
                                 $order = null, $count = null, $offset = null)</methodname>
                         </entry>
 
                         <entry>
-                            Create a DataTable object that represents the data contained in a 
-                            <classname>Zend_Db_Table_Abstract</classname> instance. For retrieving 
+                            Create a DataTable object that represents the data contained in a
+                            <classname>Zend_Db_Table_Abstract</classname> instance. For retrieving
                             the data <methodname>fetchAll()</methodname> is used, where the optional
                             parameters can be used to restrict the data table to a certain subset.
                         </entry>
@@ -192,17 +192,17 @@
         <title>Integrating Database Testing with the ControllerTestCase</title>
 
         <para>
-            Because PHP does not support multiple inheritance it is not possible to use the 
-            Controller and Database testcases in conjunction. However you can use the 
-            <classname>Zend_Test_PHPUnit_Db_SimpleTester</classname> database tester in your 
-            controller test-case to setup a database enviroment fixture for each new controller 
+            Because PHP does not support multiple inheritance it is not possible to use the
+            Controller and Database testcases in conjunction. However you can use the
+            <classname>Zend_Test_PHPUnit_Db_SimpleTester</classname> database tester in your
+            controller test-case to setup a database enviroment fixture for each new controller
             test. The Database TestCase in general is only a set of convenience functions which can
             also be accessed and used without the test case.
         </para>
 
         <example id="zend.test.phpunit.db.testing.controllerintegration.example">
             <para>
-                This example extends the User Controller Test from the 
+                This example extends the User Controller Test from the
                 <classname>Zend_Test_PHPUnit_ControllerTestCase</classname> documentation to include
                 a database setup.
             </para>
@@ -233,7 +233,7 @@ class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
 ]]></programlisting>
 
             <para>
-                Now the Flat XML dataset "initialUserFixture.xml" is used to set the database into 
+                Now the Flat XML dataset "initialUserFixture.xml" is used to set the database into
                 an initial state before each test, exactly as the DatabaseTestCase works internally.
             </para>
         </example>

documentation/manual/en/module_specs/Zend_Test-PHPUnit-Db.xml

@@ -4,30 +4,30 @@
     <title>Zend_Test_PHPUnit_Db</title>
 
     <para>
-        Coupling of data-access and the domain model often requires the use of a database for 
-        testing purposes. But the database is persistet accross different tests which leads to 
-        test results that can affect each other. Furthermore setting up the database to be able to 
-        run a test is quite some work. PHPUnit's Database extension simplifies testing with a 
-        database by offering a very simple mechanism to setup and teardown the database between 
+        Coupling of data-access and the domain model often requires the use of a database for
+        testing purposes. But the database is persistet accross different tests which leads to
+        test results that can affect each other. Furthermore setting up the database to be able to
+        run a test is quite some work. PHPUnit's Database extension simplifies testing with a
+        database by offering a very simple mechanism to setup and teardown the database between
         different tests. This component extends the PHPUnit Database extension with Zend Framework
-        specific code, such that writing database tests against a Zend Framework application is 
+        specific code, such that writing database tests against a Zend Framework application is
         simplified.
     </para>
 
     <para>
         Database Testing can be explained with two conceptual entities, DataSets and DataTables.
-        Internally the PHPUnit Database extension can build up an object structure of a database, 
+        Internally the PHPUnit Database extension can build up an object structure of a database,
         its tables and containing rows from configuration files or the real database content. This
-        abstract object graph can then be compared using assertions. A common use-case in database 
-        testing is setting up some tables with seed data, then performing some operations, and 
-        finally asserting that the operated on database-state is equal to some predefined expected 
-        state.  <classname>Zend_Test_PHPUnit_Db</classname> simplifies this task by allowing to 
+        abstract object graph can then be compared using assertions. A common use-case in database
+        testing is setting up some tables with seed data, then performing some operations, and
+        finally asserting that the operated on database-state is equal to some predefined expected
+        state.  <classname>Zend_Test_PHPUnit_Db</classname> simplifies this task by allowing to
         generate DataSets and DataTables from existing <classname>Zend_Db_Table_Abstract</classname>
         or <classname>Zend_Db_Table_Rowset_Abstract</classname> instances.
     </para>
 
     <para>
-        Furthermore this component allows to integrate any 
+        Furthermore this component allows to integrate any
         <classname>Zend_Db_Adapter_Abstract</classname> for testing wheras the original extension
         only works with <classname>PDO</classname>. A Test Adapter implementation for
         <classname>Zend_Db_Adapter_Abstract</classname> is also included in this component.  It

documentation/manual/en/ref/coding_standard.xml

@@ -1039,11 +1039,11 @@ switch ($numPeople) {
 ]]></programlisting>
 
                 <para>
-                    The <property>@category</property> annotation must have a value of "Zend". 
+                    The <property>@category</property> annotation must have a value of "Zend".
                 </para>
-                    
+
                 <para>
-                    The <property>@package</property> annotation must be assigned, and should be 
+                    The <property>@package</property> annotation must be assigned, and should be
                     equivalent to the component name of the class contained in the file; typically,
                     this will only have two segments, the "Zend" prefix, and the component name.
                 </para>
@@ -1051,7 +1051,7 @@ switch ($numPeople) {
                 <para>
                     The <property>@subpackage</property> annotation is optional.  If provided, it
                     should be the subcomponent name, minus the class prefix. In the example above,
-                    the assumption is that the class in the file is either "Zend_Magic_Wand", or 
+                    the assumption is that the class in the file is either "Zend_Magic_Wand", or
                     uses that classname as part of its prefix.
                 </para>
             </sect3>
@@ -1083,12 +1083,12 @@ switch ($numPeople) {
 ]]></programlisting>
 
                 <para>
-                    The <property>@category</property> annotation must have a value of "Zend". 
+                    The <property>@category</property> annotation must have a value of "Zend".
                 </para>
-                    
+
                 <para>
-                    The <property>@package</property> annotation must be assigned, and should be 
-                    equivalent to the component to which the class belongs; typically, this will 
+                    The <property>@package</property> annotation must be assigned, and should be
+                    equivalent to the component to which the class belongs; typically, this will
                     only have two segments, the "Zend" prefix, and the component name.
                 </para>