Merge pull request #493 from symfony-cmf/book

Book

Author: wouterj

book/database_layer.rst

@@ -181,6 +181,12 @@ After this, you have to create getters and setters for the properties.
     For more information about identifier generation strategies, refer to the
     `doctrine documentation`_
 
+.. tip::
+
+    You may want to implement ``Doctrine\ODM\PHPCR\HierarchyInterface``
+    which makes it for example possible to leverage the
+    :ref:`Sonata Admin Child Extension <bundle-core-child-admin-extension>`.
+
 .. seealso::
 
     You can also check out Doctrine's `Basic Mapping Documentation`_ for all
@@ -288,8 +294,8 @@ The repository contains all sorts of helpful methods::
 .. tip::
 
     If you use the repository class, you can also create a custom repository
-    for a specific document. This helps Seperation of Concern when using more
-    complex queries. This is similair to how it's done in Doctrine ORM, for
+    for a specific document. This helps with "Seperation of Concern" when using more
+    complex queries. This is similar to how it's done in Doctrine ORM, for
     more information read "`Custom Repository Classes`_" in the core
     documentation.
 

book/installation.rst

@@ -159,15 +159,17 @@ It assumes you have already installed Symfony CMF SE and have carefully read
 AcmeMainBundle and SimpleCmsBundle
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Symfony CMF SE comes with a default AcmeMainBundle to help you get started,
-similar to the AcmeDemoBundle provided by Symfony2. This gives you some demo
+Symfony CMF SE comes with a default AcmeDemoBundle to help you get started,
+similar to the AcmeDemoBundle provided by Symfony2 SE. This gives you some demo
 pages viewable in your browser.
 
 .. sidebar:: Where are the Controllers?
 
-    AcmeMainBundle doesn't include controllers or configuration files as you
+    AcmeDemoBundle doesn't include controllers or configuration files as you
     might expect. It contains little more than a Twig file and `Fixtures`_
-    data that was loaded into your database during installation.
+    data that was loaded into your database during installation. The biggest
+    chunk of code is the ``UnitBlock`` that provides a document for an example
+    block.
 
     The controller logic is actually provided by the relevant CMF bundles,
     as described below.
@@ -211,7 +213,7 @@ Adding new pages
 ~~~~~~~~~~~~~~~~
 
 Symfony CMF SE does not provide any admin tools to create new pages. If you
-are interested in adding an admin UI have a look at
+are interested in adding an admin UI one solution can be found in
 :doc:`../cookbook/creating_cms_using_cmf_and_sonata`. However if all you want
 is a simple way to add new pages that you can then edit via the inline
 editing, then you can use the SimpleCmsBundle ``page`` migrator. The Symfony

book/simplecms.rst

@@ -6,13 +6,13 @@ First look at the internals
 
 In most CMS use cases the most basic need is to associate content with a URL.
 In the Symfony CMF, this is done by using a powerful routing system, provided
-by the RoutingBundle, and a ContentBundle. The RoutingBundle provides a
+by the RoutingBundle, and the ContentBundle. The RoutingBundle provides a
 ``Route`` object which can be associated with the ``Content`` object of the
 ContentBundle.
 
 Having two objects is the most flexible solution. You can have different
 routes (e.g. per language) for the same content. Or you can organize your
-content in a different logic than your URL tree. But in many situations,
+content in a differently than your URL tree. But in many situations,
 having the route and the content be one and the same simplifies things. That
 is exactly what the SimpleCmsBundle is doing, which is used by the Symfony
 CMF Standard Edition by default for routing, content and menus.

book/static_content.rst

@@ -25,37 +25,16 @@ fields are self explanatory and are what you would expect from a basic CMS:
 title, body, publishing information and a parent reference, to accommodate a
 tree-like hierarchy. It also includes a Block reference (more on that later).
 
-The two implemented interfaces reveal two of the features included in this
-implementation:
+This document class implements three interfaces that enable additional functionality:
 
 * ``RouteReferrersInterface`` means that the content has associated Routes.
-* ``PublishWorkflowInterface`` means that the content has publishing and
+* ``PublishTimePeriodInterface`` means that the content has publishing and
    unpublishing dates, which will be handled by Symfony CMF's core to
+   determine whether or not to display the content from ``StaticContent``
+* ``PublishableInterface`` means that the content has a boolean flag,
+   which will be handled by Symfony CMF's core to
    determine whether or not to display the content from ``StaticContent``.
 
-Multilang Static Content
-------------------------
-
-The ``MultilangStaticContent`` class extends ``StaticContent``, offering the same
-functionality with multi language support. It specifies which fields are to be
-translated (``title``, ``body`` and ``tags``) as well as a variable to declare
-the locale.
-
-It also specifies the translation strategy:
-
-.. configuration-block::
-
-    .. code-block:: php-annotations
-
-        use Doctrine\ODM\PHPCR\Mapping\Annotations as PHPCR;
-
-        /**
-         * @PHPCR\Document(translator="child", referenceable=true)
-         */
-
-For information on the available translation strategies, refer to the Doctrine
-page regarding `multilanguage support in PHPCR-ODM`_.
-
 Content Controller
 ------------------
 

book/structuring_content.rst

@@ -139,9 +139,9 @@ implement ``NodeInterface`` in order to be included in the generated menu.
 The Menu Nodes
 ..............
 
-Also included in the MenuBundle are two menu node content types: ``MenuNode``
-and ``MultilangMenuNode``. If you have read the documentation page regarding
-:doc:`static_content`, you'll find this implementation somewhat familiar.
+Also included in the MenuBundle is the ``MenuNode`` document. If you have
+read the documentation page regarding :doc:`static_content`, you'll find
+this implementation somewhat familiar.
 
 ``MenuNode`` implements the above mentioned ``NodeInterface``, and holds the
 information regarding a single menu entry: a ``label`` and a ``uri``, a
@@ -155,25 +155,6 @@ ensured) reference to the actual Content element it points to; it's up to you
 to choose which best fits your scenario. You can find more information on
 references on the `Doctrine PHPCR documentation page`_.
 
-``MultilangMenuNode`` extends ``MenuNode`` with multilanguage support. It adds
-a ``locale`` field to identify which translation set it belongs to, plus
-``label`` and ``uri`` fields marked as ``translated=true``. This means they
-will differ between translations, unlike the other fields.
-
-``MultilangMenuNode`` also specifies the strategy used to persist multiple
-translations:
-
-.. configuration-block::
-
-    .. code-block:: php-annotations
-
-        /**
-         * @PHPCR\Document(translator="attribute")
-         */
-
-For information on the available translation strategies, refer to the Doctrine
-page regarding `Multi language support in PHPCR-ODM`_
-
 Admin Support
 ~~~~~~~~~~~~~
 
@@ -197,6 +178,5 @@ configuration options list and additional information.
 .. _`KnpMenuBundle's documentation`: https://github.com/KnpLabs/KnpMenuBundle/blob/master/Resources/doc/index.md
 .. _`respective documentation page`: https://github.com/KnpLabs/KnpMenuBundle/blob/master/Resources/doc/index.md#rendering-menus
 .. _`Doctrine PHPCR documentation page`: http://docs.doctrine-project.org/projects/doctrine-phpcr-odm/en/latest/reference/association-mapping.html#references
-.. _`Multi language support in PHPCR-ODM`: http://docs.doctrine-project.org/projects/doctrine-phpcr-odm/en/latest/reference/multilang.html
 .. _`KnpMenu`: https://github.com/knplabs/KnpMenu
 .. _SonataDoctrinePHPCRAdminBundle: http://sonata-project.org/bundles/doctrine-phpcr-admin/master/doc/index.html