Merge pull request #1562 from caponica/docs-20130810

Small updates to documentation

Resources/doc/index.rst

@@ -24,6 +24,11 @@ Reference Guide
    reference/architecture
    reference/dashboard
    reference/routing
+   reference/action_list
+   reference/action_create_edit
+   reference/action_show
+   reference/action_delete
+   reference/action_export
    reference/saving_hooks
    reference/form_types
    reference/form_help_message

Resources/doc/reference/action_export.rst

@@ -0,0 +1,26 @@
+The Export action
+===============
+
+.. note::
+
+    This document is a stub representing a new work in progress. If you're reading 
+    this you can help contribute, **no matter what your experience level with Sonata 
+    is**. Check out the `issues on Github`_ for more information about how to get involved.
+
+This document will cover the Export action and related configuration options.
+
+
+Basic configuration
+-------------------
+
+To do:
+
+- any global (yml) options that affect the export actions
+- how to disable (some of) the default formats
+- how to add new export formats
+- customising the templates used to render the output
+- customising the query used to fetch the results
+
+
+
+.. _`issues on Github`: https://github.com/sonata-project/SonataAdminBundle/issues/1519

Resources/doc/reference/form_types.rst

@@ -46,16 +46,18 @@ to the underlying forms.
         }
     }
 
-**TIP**: A jQuery event is fired after a row has been added(*sonata-collection-item-added*) or deleted(*sonata-collection-item-deleted*). You can bind to them to trigger some custom javascript imported into your templates(eg: add a calendar widget to a just added date field)
+**TIP**: A jQuery event is fired after a row has been added (``sonata-collection-item-added``) 
+or deleted (``sonata-collection-item-deleted``). You can bind to these events to trigger custom 
+javascript imported into your templates (eg: add a calendar widget to a newly added date field)
 
 Field configuration
 ^^^^^^^^^^^^^^^^^^^
 
 - ``admin_code``: Force for any field involving a model the admin class used to 
-    handle it (useful for inline editing with ``sonata_type_admin``). The 
-    expected value here is the admin service name, not the class name. If not 
-    defined, the default admin class for the model type will be used (even if 
-    you didn't define any admin for the model type).
+  handle it (useful for inline editing with ``sonata_type_admin``). The 
+  expected value here is the admin service name, not the class name. If not 
+  defined, the default admin class for the model type will be used (even if 
+  you didn't define any admin for the model type).
 
 Other specific field configuration options are detailed in the related 
 abstraction layer documentation.

Resources/doc/reference/translation.rst

@@ -15,29 +15,29 @@ You have two options to configure the catalogue for the Admin class:
 
 * by over-riding the ``$translationDomain`` property
 
-    .. code-block:: php
+  .. code-block:: php
 
-        <?php
-        class PageAdmin extends Admin
-        {
-            protected $translationDomain = 'SonataPageBundle'; // default is 'messages'
-        }
+      <?php
+      class PageAdmin extends Admin
+      {
+          protected $translationDomain = 'SonataPageBundle'; // default is 'messages'
+      }
 
 
 * or by injecting the value through the container
 
-    .. code-block:: xml
+  .. code-block:: xml
 
-            <service id="sonata.page.admin.page" class="Sonata\PageBundle\Admin\PageAdmin">
-                <tag name="sonata.admin" manager_type="orm" group="sonata_page" label="page"/>
-                <argument />
-                <argument>Application\Sonata\PageBundle\Entity\Page</argument>
-                <argument />
+          <service id="sonata.page.admin.page" class="Sonata\PageBundle\Admin\PageAdmin">
+              <tag name="sonata.admin" manager_type="orm" group="sonata_page" label="page"/>
+              <argument />
+              <argument>Application\Sonata\PageBundle\Entity\Page</argument>
+              <argument />
 
-                <call method="setTranslationDomain">
-                    <argument>SonataPageBundle</argument>
-                </call>
-            </service>
+              <call method="setTranslationDomain">
+                  <argument>SonataPageBundle</argument>
+              </call>
+          </service>
 
 
 An Admin instance always gets the ``translator`` instance, so it can be used to
@@ -81,24 +81,24 @@ Setting the translation domain on an individual field:
 
 .. code-block:: php
 
-        $formMapper->with('form.my_group')
-            ->add('publishable', 'checkbox', array(), array(
-                'translation_domain' => 'MyTranslationDomain',
-            ))
-        ;
+    $formMapper->with('form.my_group')
+        ->add('publishable', 'checkbox', array(), array(
+            'translation_domain' => 'MyTranslationDomain',
+        ))
+    ;
 
 The following example sets the default translation domain on a form group and 
 over-rides that setting for one of the fields:
 
 .. code-block:: php
 
-        $formMapper
-            ->with('form.my_group', array('translation_domain' => 'MyDomain'))
-                ->add('publishable', 'checkbox', array(), array(
-                    'translation_domain' => 'AnotherDomain',
-                ))
-                ->add('start_date', 'date', array(), array())
-        ;
+    $formMapper
+        ->with('form.my_group', array('translation_domain' => 'MyDomain'))
+            ->add('publishable', 'checkbox', array(), array(
+                'translation_domain' => 'AnotherDomain',
+            ))
+            ->add('start_date', 'date', array(), array())
+    ;
 
 Setting the label name
 ^^^^^^^^^^^^^^^^^^^^^^
@@ -128,24 +128,25 @@ There is another option for rapid prototyping or to avoid spending too much time
 adding the ``label`` key to all option fields: **Label Strategies**. By default
 labels are generated by using a simple rule:
 
+.. code-block
+
     isValid => Is Valid
 
+
 The ``AdminBundle`` comes with different key label generation strategies:
 
-* ``sonata.admin.label.strategy.native``: DEFAULT - Makes the string human 
+- ``sonata.admin.label.strategy.native``: DEFAULT - Makes the string human 
   readable
     ``isValid`` => ``Is Valid``
-* ``sonata.admin.label.strategy.form_component``: The default behavior from the Form 
+- ``sonata.admin.label.strategy.form_component``: The default behavior from the Form 
   Component
     ``isValid`` => ``Isvalid``
-* ``sonata.admin.label.strategy.underscore``: Changes the name into a token suitable for 
+- ``sonata.admin.label.strategy.underscore``: Changes the name into a token suitable for 
   translation by prepending "form.label" to an underscored version of the field name
     ``isValid`` => ``form.label_is_valid``
-* ``sonata.admin.label.strategy.noop``: does not alter the 
+- ``sonata.admin.label.strategy.noop``: does not alter the 
   string
     ``isValid`` => ``isValid``
-* ``sonata.admin.label.strategy.bc``: preserves the old label generation from the 
-  early version of ``SonataAdminBundle``
 
 ``sonata.admin.label.strategy.underscore`` will be better for i18n applications
 and ``sonata.admin.label.strategy.native`` will be better for native (single) language
@@ -180,5 +181,6 @@ the Container:
 
 .. note::
 
-    When the strategy method is called, a context (form, filter, list, show) and
-    a type (link, label, etc ...) arguments are passed.
+    When the strategy method is called, ``context`` (breadcrumb, datagrid, filter, 
+    form, list, show, etc.) and ``type`` (usually link or label) arguments are passed. 
+    For example, the call may look like: ``getLabel($label_key, 'breadcrumb', 'link')``