Merge branch 'hotfix/34' into develop

Forward port #34

book/zend.form.collections.md

@@ -420,15 +420,15 @@ entity.
 This element has a few interesting options:
 
 - `count`: this is how many times the element (in this case a category) has to be rendered. We've
-set it to two in this examples.
+  set it to two in this examples.
 - `should_create_template`: if set to `true`, it will generate a template markup in a `<span>`
-element, in order to simplify adding new element on the fly (we will speak about this one later).
+  element, in order to simplify adding new element on the fly (we will speak about this one later).
 - `allow_add`: if set to `true` (which is the default), dynamically added elements will be retrieved
-and validated; otherwise, they will be completely ignored. This, of course, depends on what you want
-to do.
+  and validated; otherwise, they will be completely ignored. This, of course, depends on what you want
+  to do.
 - `target_element`: this is either an element or, as this is the case in this example, an array that
-describes the element or fieldset that will be used in the collection. In this case, the
-`target_element` is a `Category` fieldset.
+  describes the element or fieldset that will be used in the collection. In this case, the
+  `target_element` is a `Category` fieldset.
 
 ## The Form Element
 
@@ -551,13 +551,13 @@ echo $this->form()->closeTag();
 A few new things here :
 
 - the `prepare()` method. You *must* call it prior to rendering anything in the view (this function
-is only meant to be called in views, not in controllers).
+  is only meant to be called in views, not in controllers).
 - the `FormRow` helper renders a label (if present), the input itself, and errors.
 - the `FormCollection` helper will iterate through every element in the collection, and render every
-element with the FormRow helper (you may specify an alternate helper if desired, using the
-`setElementHelper()` method on that `FormCollection` helper instance). If you need more control
-about the way you render your forms, you can iterate through the elements in the collection, and
-render them manually one by one.
+  element with the FormRow helper (you may specify an alternate helper if desired, using the
+  `setElementHelper()` method on that `FormCollection` helper instance). If you need more control
+  about the way you render your forms, you can iterate through the elements in the collection, and
+  render them manually one by one.
 
 Here is the result:
 
@@ -629,7 +629,7 @@ The `add_category` function is fairly simple:
 
 Here is the code:
 
-```php
+```javascript
 <script>
     function add_category() {
         var currentCount = $('form > fieldset > fieldset').length;
@@ -679,13 +679,13 @@ $this->add(array(
 There are some limitations to this capability:
 
 - Although you can add new elements and remove them, you *CANNOT* remove more elements in a
-collection than the initial count (for instance, if your code specifies `count == 2`, you will be
-able to add a third one and remove it, but you won't be able to remove any others. If the initial
-count is 2, you *must* have at least two elements.
+  collection than the initial count (for instance, if your code specifies `count == 2`, you will be
+  able to add a third one and remove it, but you won't be able to remove any others. If the initial
+  count is 2, you *must* have at least two elements.
 - Dynamically added elements have to be added at the end of the collection. They can be added
-anywhere (these elements will still be validated and inserted into the entity), but if the
-validation fails, this newly added element will be automatically be replaced at the end of the
-collection.
+  anywhere (these elements will still be validated and inserted into the entity), but if the
+  validation fails, this newly added element will be automatically be replaced at the end of the
+  collection.
 
 ## Validation groups for fieldsets and collection
 

book/zend.form.elements.md

@@ -481,9 +481,9 @@ string. The following keys are supported:
 - `"selected"` - Boolean that sets whether the option is marked as selected.
 - `"disabled"` - Boolean that sets whether the option will be disabled
 - `"attributes"` - Array of html attributes that will be set on this option. Merged with the
-attributes set on the element.
+  attributes set on the element.
 - `"label_attributes"` - Array of html attributes that will be set on the label. Merged with the
-attributes set on the element's label.
+  attributes set on the element's label.
 
 ```php
 $form = new Form('my-form');

book/zend.form.file-upload.md

@@ -59,12 +59,12 @@ class UploadForm extends Form
 The `File` element provides some automatic features that happen behind the scenes:
 
 - The form's `enctype` will automatically be set to `multipart/form-data` when the form `prepare()`
-method is called.
+  method is called.
 - The file element's default input specification will create the correct `Input` type:
-\[Zend\\InputFilter\\FileInput\](zend.input-filter.file-input).
+  \[Zend\\InputFilter\\FileInput\](zend.input-filter.file-input).
 - The `FileInput` will automatically prepend an \[UploadFile
-Validator\](zend.validator.file.upload-file), to securely validate that the file is actually an
-uploaded file, and to report other types of upload errors to the user.
+  Validator\](zend.validator.file.upload-file), to securely validate that the file is actually an
+  uploaded file, and to report other types of upload errors to the user.
 
 ### The View Template
 
@@ -297,10 +297,10 @@ information on its supported options.
 Behind the scenes, the `FilePRG` plugin will:
 
 - Run the Form's filters, namely the `RenameUpload` filter, to move the files out of temporary
-storage.
+  storage.
 - Store the valid POST data in the session across requests.
 - Change the `required` flag of any file inputs that had valid uploads to `false`. This is so that
-form re-submissions without uploads will not cause validation errors.
+  form re-submissions without uploads will not cause validation errors.
 
 > ## Note
 In the case of a partially valid form, it is up to the developer whether to notify the user that
@@ -656,5 +656,5 @@ Related documentation:
 External resources and blog posts from the community:
 
 - [ZF2FileUploadExamples](https://github.com/cgmartin/ZF2FileUploadExamples) : A ZF2 module with
-several file upload examples.
+  several file upload examples.
 

book/zend.form.intro.md

@@ -9,8 +9,8 @@ The `Zend\Form` component consists of the following objects:
 - `Elements`, which simply consist of a name and attributes.
 - `Fieldsets`, which extend from `Elements`, but allow composing other fieldsets and elements.
 - `Forms`, which extend from `Fieldsets` (and thus `Elements`). They provide data and object
-binding, and compose \[InputFilters\](zend.input-filter.intro). Data binding is done via
-\[Zend\\Stdlib\\Hydrator\](zend.stdlib.hydrator).
+  binding, and compose \[InputFilters\](zend.input-filter.intro). Data binding is done via
+  \[Zend\\Stdlib\\Hydrator\](zend.stdlib.hydrator).
 
 To facilitate usage with the view layer, the `Zend\Form` component also aggregates a number of
 form-specific view helpers. These accept elements, fieldsets, and/or forms, and use the attributes

book/zend.form.quick-start.md

@@ -519,7 +519,7 @@ class SenderFieldset extends Fieldset implements InputFilterProviderInterface
                 ),
                 'validators' => array(
                     array(
-                        'name' => 'Zend\Validator\StringLength', 
+                        'name' => 'Zend\Validator\StringLength',
                         'options' => array(
                             'min' => 3,
                             'max' => 256
@@ -561,15 +561,15 @@ that in action.
 When you `bind()` an object to the form, the following happens:
 
 - The composed `Hydrator` calls `extract()` on the object, and uses the values returned, if any, to
-populate the `value` attributes of all elements. If a form contains a fieldset that itself contains
-another fieldset, the form will recursively extract the values.
+  populate the `value` attributes of all elements. If a form contains a fieldset that itself contains
+  another fieldset, the form will recursively extract the values.
 - When `isValid()` is called, if `setData()` has not been previously set, the form uses the composed
-`Hydrator` to extract values from the object, and uses those during validation.
+  `Hydrator` to extract values from the object, and uses those during validation.
 - If `isValid()` is successful (and the `bindOnValidate` flag is enabled, which is true by default),
-then the `Hydrator` will be passed the validated values to use to hydrate the bound object. (If you
-do not want this behavior, call `setBindOnValidate(FormInterface::BIND_MANUAL)`).
+  then the `Hydrator` will be passed the validated values to use to hydrate the bound object. (If you
+  do not want this behavior, call `setBindOnValidate(FormInterface::BIND_MANUAL)`).
 - If the object implements `Zend\InputFilter\InputFilterAwareInterface`, the input filter it
-composes will be used instead of the one composed on the form.
+  composes will be used instead of the one composed on the form.
 
 This is easier to understand in practice.
 
@@ -858,46 +858,46 @@ annotations in `Zend\Form`:
 
 - *AllowEmpty*: mark an input as allowing an empty value. This annotation does not require a value.
 - *Attributes*: specify the form, fieldset, or element attributes. This annotation requires an
-associative array of values, in a JSON object format:
-`@Attributes({"class":"zend_form","type":"text"})`.
+  associative array of values, in a JSON object format:
+  `@Attributes({"class":"zend_form","type":"text"})`.
 - *ComposedObject*: specify another object with annotations to parse. Typically, this is used if a
-property references another object, which will then be added to your form as an additional fieldset.
-Expects a string value indicating the class for the object being composed
-`@ComposedObject("Namespace\Model\ComposedObject")` or an array to compose a collection:
-`@ComposedObject({ "target_object":"Namespace\Model\ComposedCollection", "is_collection":"true",
-"options":{"count":2}})` `target_object` is the element to compose, `is_collection` flags this as a
-collection and `options` can take an array of options to pass into the collection.
+  property references another object, which will then be added to your form as an additional fieldset.
+  Expects a string value indicating the class for the object being composed
+  `@ComposedObject("Namespace\Model\ComposedObject")` or an array to compose a collection:
+  `@ComposedObject({ "target_object":"Namespace\Model\ComposedCollection", "is_collection":"true",
+  "options":{"count":2}})` `target_object` is the element to compose, `is_collection` flags this as a
+  collection and `options` can take an array of options to pass into the collection.
 - *ErrorMessage*: specify the error message to return for an element in the case of a failed
-validation. Expects a string value.
+  validation. Expects a string value.
 - *Exclude*: mark a property to exclude from the form or fieldset. This annotation does not require
-a value.
+  a value.
 - *Filter*: provide a specification for a filter to use on a given element. Expects an associative
-array of values, with a "name" key pointing to a string filter name, and an "options" key pointing
-to an associative array of filter options for the constructor: `@Filter({"name": "Boolean",
-"options": {"casting":true}})`. This annotation may be specified multiple times.
+  array of values, with a "name" key pointing to a string filter name, and an "options" key pointing
+  to an associative array of filter options for the constructor: `@Filter({"name": "Boolean",
+  "options": {"casting":true}})`. This annotation may be specified multiple times.
 - *Flags*: flags to pass to the fieldset or form composing an element or fieldset; these are usually
-used to specify the name or priority. The annotation expects an associative array:
-`@Flags({"priority": 100})`.
+  used to specify the name or priority. The annotation expects an associative array:
+  `@Flags({"priority": 100})`.
 - *Hydrator*: specify the hydrator class to use for this given form or fieldset. A string value is
-expected.
+  expected.
 - *InputFilter*: specify the input filter class to use for this given form or fieldset. A string
-value is expected.
+  value is expected.
 - *Input*: specify the input class to use for this given element. A string value is expected.
 - *Instance*: specify an object class instance to bind to the form or fieldset.
 - *Name*: specify the name of the current element, fieldset, or form. A string value is expected.
 - *Object*: specify an object class instance to bind to the form or fieldset. (Note: this is
-deprecated in 2.4.0; use *Instance* instead.)
+  deprecated in 2.4.0; use *Instance* instead.)
 - *Options*: options to pass to the fieldset or form that are used to inform behavior -- things that
-are not attributes; e.g. labels, CAPTCHA adapters, etc. The annotation expects an associative array:
-`@Options({"label": "Username:"})`.
+  are not attributes; e.g. labels, CAPTCHA adapters, etc. The annotation expects an associative array:
+  `@Options({"label": "Username:"})`.
 - *Required*: indicate whether an element is required. A boolean value is expected. By default, all
-elements are required, so this annotation is mainly present to allow disabling a requirement.
+  elements are required, so this annotation is mainly present to allow disabling a requirement.
 - *Type*: indicate the class to use for the current element, fieldset, or form. A string value is
-expected.
+  expected.
 - *Validator*: provide a specification for a validator to use on a given element. Expects an
-associative array of values, with a "name" key pointing to a string validator name, and an "options"
-key pointing to an associative array of validator options for the constructor: `@Validator({"name":
-"StringLength", "options": {"min":3, "max": 25}})`. This annotation may be specified multiple times.
+  associative array of values, with a "name" key pointing to a string validator name, and an "options"
+  key pointing to an associative array of validator options for the constructor: `@Validator({"name":
+  "StringLength", "options": {"min":3, "max": 25}})`. This annotation may be specified multiple times.
 
 To use annotations, you simply include them in your class and/or property docblocks. Annotation
 names will be resolved according to the import statements in your class; as such, you can make them