Skip to content
This repository has been archived by the owner on Apr 2, 2018. It is now read-only.

Commit

Permalink
Merge pull request #9 from marnusw/spelling_mistakes
Browse files Browse the repository at this point in the history
Fixed two spelling mistakes in the introduction.
  • Loading branch information
lsmith77 committed Apr 4, 2012
2 parents 3e272b5 + a5d7c1c commit 20bcbc8
Show file tree
Hide file tree
Showing 2 changed files with 4 additions and 4 deletions.
4 changes: 2 additions & 2 deletions en/reference/configuration.rst
Expand Up @@ -5,7 +5,7 @@ Bootstrapping
-------------

Bootstrapping Doctrine is a relatively simple procedure that
roughly exists of just 2 steps:
roughly consists of just 2 steps:


- Making sure Doctrine class files can be loaded on demand.
Expand All @@ -21,7 +21,7 @@ Doctrine CouchDB has dependencies on two other libraries:

You have to make sure that both dependencies are installed and autoloadable.

The Github checkout of comes with a submodule of the Doctrine Common library. It contains
The Github checkout comes with a submodule of the Doctrine Common library. It contains
the ``Doctrine\Common\ClassLoader`` which should be used for autoloading all the necessary
Doctrine classes.

Expand Down
4 changes: 2 additions & 2 deletions en/reference/introduction.rst
Expand Up @@ -21,7 +21,7 @@ Features
Architecture
------------

The Doctrine persistence semantics demand a strict separation of persistence and business logic. This means the PHP Objects that you can map to CouchDB documents do not extend any base class or implement any interface. These objects and their associations between each other don't even know that they are saved inside the CouchDB, fow all they know it could also be the ORM or MongoDB solving their persistence needs. Instead of having ``save()``, ``delete()`` and finder methods on your PHP objects Doctrine CouchDB ODM provides you with a management/query layer that translates between CouchDB documents and PHP objects.
The Doctrine persistence semantics demand a strict separation of persistence and business logic. This means the PHP Objects that you can map to CouchDB documents do not extend any base class or implement any interface. These objects and their associations between each other don't even know that they are saved inside the CouchDB, for all they know it could also be the ORM or MongoDB solving their persistence needs. Instead of having ``save()``, ``delete()`` and finder methods on your PHP objects Doctrine CouchDB ODM provides you with a management/query layer that translates between CouchDB documents and PHP objects.

For example take this BlogPost entity:

Expand Down Expand Up @@ -86,7 +86,7 @@ No abstract/base-class nor interface was implemented, yet you can save an object
text: { type: string }
publishDate: { type: datetime }
This simple definitions describe to Doctrine CouchDB ODM what parts of your object should be mapped. Now your application code saving an instance of a blog post will look like the following lines:
These simple definitions describe to Doctrine CouchDB ODM what parts of your object should be mapped. Now your application code saving an instance of a blog post will look like the following lines:

.. code-block:: php
Expand Down

0 comments on commit 20bcbc8

Please sign in to comment.