Add missing options, add method arguments lists with descriptions, examples and definitions #4598

admusin · 2017-01-12T14:45:41Z

Add code tags around names of: methods, arguments, attributes, options, HTML elements, where missing.
Add argument list with description for each method on the page
Add list of used templates after method description, in all method where it applies.
Add Form::create() options list with description in new subsection
Add missing options in options list for: input() and add details in some option definitions.
Reword Input Options descriptions to keep current definition but start by option type specification.
Clarify in introduction of Common Options for Specific Inputs that the options will be provided either in $options or in $attributes depending on the method
Create subsection for Checkbox, Select and Radio and move common Options for Select, Checkbox and Radio at beginning of that subsection for easier reference.
Clarify in Options for Select, Checkbox and Radio when 'value' and 'empty' will do for each method
Indent code block examples inside all options lists, one level further, in order to allow faster and easier scan of the list and differentiation between definitions/descriptions and examples.
Create subsection for Date & Time controls and move common Options for Date & Time at beginning of this subsection for easier reference.
Separate Options for Date & Time in 3 sub-subsections: Common Options for Date & Time, Options for Date and Options for Time
Add missing Date & Time options from API source code comments, along with explanations.
Add missing date() method subsection inside the Date & Time section along with example.
Improve explanations of Date & Time options based on comments in API source code.
Add ref links from each Date & Time method arguments description towards: common input options, common datetime options and respectively common date or time options (depending on method).
Transform textual note at the end of Creating Month Inputs into reST note.
Add example output for minutes interval example code, in Creating Minute Inputs.
Regroup options specific to any one particular method inside a list in the method's section; easier to identify and skim through.
Add 2 subsections inside Displaying and Checking errors; one for each method for easier reference from TOC.
Create 2 subsections inside Creating Buttons and Submit Elements: one for submits and one for buttons; allows easier access from TOC.
Create 2 subsections inside Creating Standalone Buttons and POST Links; allows easier access from TOC.
Create 2 subsections inside Generating Entire Forms: allows easier access from TOC.
Add reST note about additional options passed to Submit, being passed to the input element.
Elaborate definition in Creating Submit Elements subsection, based on API source-code comments.
Change last example code block inside inputs() method to use the actual method instead of allInputs().
Add reST note in Creating Form Inputs to remind that elements generated by input() are always wrapped in divs.
Elaborate description for error() and add reST tip about use of validator messages.
Improve and expand some definitions and explanations across page, based on detailed comments from API source code.
Expand explanation introducing the autodetected datatypes in Creating Form Inputs.
Add links to context provider classes in API from each entry in the list of built-in context providers in Starting a Form section.
Clarify in Moving Checkboxes and Radios Outside of a Label that only checkboxes created via input() are wrapped in a label.
Add details about radio button creation methods in Moving Checkboxes and Radios Outside of a Label

Add the default widget templates into beginning of Creating Form Inputs subsection to make it clear right away what HTML the method generates; Small formatting improvements from start of page up to Creating Input Elements section, for better readability of small code elements.

Add note in Creating Form Inputs section to remind that input method generates wrapping divs. Add small formatting in the same section - wrap in code tags all pure text element or method names to make page consistent with itself Disambiguate and/or clarify small phrase parts in the same section.

Disambiguate the initial description of Common Options; the options with go in either $options or $attributes array, depending on the chosen method; Eliminate '$options' from the name of each option entry in the description to avoid confusion; Reformat element/option names or values with code tags to follow general style of the page and improve readability; Rephrase/clarify some unclear wording up to Creating Input Elements section.

Add code formatting tags on element, key, value, method names where missing, from beginning of "Creating Input Elements" up to beginning of "Creating Buttons and Submit Elements"; Add missing examples in the same area of document; Correct/disambiguate some explanations in the same area of document; Add the list of arguments with short description right after the method name in each subsection; Add (where existent) the widget template at beginning of method description to make clear what HTML is output.

Add after each method arguments under each method name with short description for each argument from the beginning of "Creating Buttons and Submit Elements" until beginning of "Creating Inputs for Associated Data"; Add missing examples in various places in the same document area; Format element, attribute, key, property names with code tags to improve readability and page consistency;

Add line breaks in the note present inside Creating Form Inputs

Reformat long lines that don't contain code to fit into 80 chars. Add more detailed description for secure(), from source code description. Fix few small spell-checking errors. Add arguments description for methods in the last part of page starting from Creating Inputs for Associated data till the end of page.

Reformat own added/modified text to fit the 80 chars limtit. Correct own description of fieldname in date/time related methods. Reword Input Options descriptions to keep current definition but start by option type specification. Indent all example/output code block pairs to allow faster scanning of page sections and differentiation from definitions/descriptions in long option lists. Add missing Input Options: 'options', 'nestedInput' and 'templates' along with descriptions from source code API comments. Create section for Select, Checkbox and Radio and move their specific options into that section. Add missing explanations on how 'value' option behaves on checkbox and radio buttons and how 'empty' behaves on radio buttons based on source code API comments. Create section for DateTime controls and move their specific options into that section; transform each date/time method section into subsection. Move all common options for date/time from each date and time method into the beginning of DateTime section and split in Options for Date and Options for Time. Add missing date/time options in the Date Options and Time options sub-sections from source code API comments. Improve and explanations for time/date-related options based on comments of source code API. Improve descriptions for certain time/date-related methods based on comments of source code API. Add example for dateTime() default method output. Add missing date() method with arguments description, definition and example based on API source code. Add ref links from each date and time method arguments description towards the commong datetime options subsection and respectively date-options or time-options subsections. Transform textual note at end of Creating Month Inputs into reST note. Add example output for minutes interval example in Creating Minute Inputs. Add, inside Displaying and Checking Errors, subsections for Displaying Errors and Checking for Errors to allow easier identification and direct navigation from TOC. Improve arguments description for error() based on API source code comments. Improve description for error() and add reST tip about using validator rules error messages when the same custom message is desired. Create subsections inside Creating Buttons and Submit elements: Creating Submit Elements and Creating Button Elements to allow easier finding of each method via TOC. Expand definition in Creating Submit Elements sub-section based on API source-code comments. Add note about additional options provided to Submit being passed to input element if not recognized as submit-specific. Create subsections inside Creating Standalong Buttons and POST Links: Creating POST Buttons and Creating POST Links to allow easier finding each method via TOC. Add subsections inside Generating Entire Forms: Creating Multiple Inputs and Creating Inputs for a Whole Entity to allow easier finding of each method via TOC. Change last example inside inputs() method to use the actual method instead of allInputs(). Small improvements in text description in multiple places on the page.

Change "next" with "a following" in Starting a Form, as the section referring to Context doesn't come first after that paragraph Add empty lines between $model built-in providers enumeration to improve readability Add links to context provider classes in each enumeration Add new sub-section in Starting a Form, named Options for Form, which contains the valid options for create() method

Fix indenting for some notes.

…ds original Small indenting fixes.

…ting Form Inputs Expand explanation in the introduction for autodetected datatypes in Creating Form Inputs Fix own indentation mistakes Fix own small ortography mistakes Add <option> template at beginning of Create Select Pickers Add optional templates at beginning of Create Select Pickers Add specification about checkboxes created via input() in Moving Checkboxes and Radios Outside of a Label

Consolidation commit before pull request: Add code tags around names of: methods, arguments, attributes, options, HTML elements, where missing. Add argument list with description for each method on the page Add list of used templates after method description, in all method where it applies. Add Form::create() options list with description in new subsection Add missing options in options list for: input() and add details in some option definitions. Reword Input Options descriptions to keep current definition but start by option type specification. Clarify in introduction of Common Options for Specific Inputs that the options will be provided either in $options or in $attributes depending on the method Create subsection for Checkbox, Select and Radio and move common Options for Select, Checkbox and Radio at beginning of that subsection for easier reference. Clarify in Options for Select, Checkbox and Radio when 'value' and 'empty' will do for each method Indent code block examples inside all options lists, one level further, in order to allow faster and easier scan of the list and differentiation between definitions/descriptions and examples. Create subsection for Date & Time controls and move common Options for Date & Time at beginning of this subsection for easier reference. Separate Options for Date & Time in 3 sub-subsections: Common Options for Date & Time, Options for Date and Options for Time Add missing Date & Time options from API source code comments, along with explanations. Add missing date() method subsection inside the Date & Time section along with example. Improve explanations of Date & Time options based on comments in API source code. Add ref links from each Date & Time method arguments description towards: common input options, common datetime options and respectively common date or time options (depending on method). Transform textual note at the end of Creating Month Inputs into reST note. Add example output for minutes interval example code, in Creating Minute Inputs. Regroup options specific to any one particular method inside a list in the method's section; easier to identify and skim through. Add 2 subsections inside Displaying and Checking errors; one for each method for easier reference from TOC. Create 2 subsections inside Creating Buttons and Submit Elements: one for submits and one for buttons; allows easier access from TOC. Create 2 subsections inside Creating Standalone Buttons and POST Links; allows easier access from TOC. Create 2 subsections inside Generating Entire Forms: allows easier access from TOC. Add reST note about additional options passed to Submit, being passed to the input element. Elaborate definition in Creating Submit Elements subsection, based on API source-code comments. Change last example code block inside inputs() method to use the actual method instead of allInputs(). Add reST note in Creating Form Inputs to remind that elements generated by input() are always wrapped in divs. Elaborate description for error() and add reST tip about use of validator messages. Improve and expand some definitions and explanations across page, based on detailed comments from API source code. Expand explanation introducing the autodetected datatypes in Creating Form Inputs. Add links to context provider classes in API from each entry in the list of built-in context providers in Starting a Form section. Clarify in Moving Checkboxes and Radios Outside of a Label that only checkboxes created via input() are wrapped in a label. Add details about radio button creation methods in Moving Checkboxes and Radios Outside of a Label

markstory

Thank you for the changes. The extra detail will be helpful for lots of folks.

In the future, I would recommend you make these kinds of changes in smaller pieces, as very large pull requests are time consuming to create, review, and land.

markstory · 2017-01-12T20:17:16Z

en/views/helpers/form.rst

+``$model``:
+
+* An ``Entity`` instance or an iterator will map to
+  `EntityContext <https://api.cakephp.org/3.3/class-Cake.View.Form.EntityContext.html>`;


You're missing _ on the end of this link.

Fixed in current commit.

markstory · 2017-01-12T20:17:54Z

en/views/helpers/form.rst

+  built-in ORM.
+
+* An array containing the ``'schema'`` key, will map to
+  `ArrayContext <https://api.cakephp.org/3.3/class-Cake.View.Form.ArrayContext.html>`


And this one.

Fixed in current commit.

markstory · 2017-01-12T20:18:08Z

en/views/helpers/form.rst

+  which allows you to create simple data structures to build forms against.
+
+* ``null`` and ``false`` will map to
+  ``NullContext <https://api.cakephp.org/3.3/class-Cake.View.Form.NullContext.html>``;


This link is also incorrect.

Fixed in current commit.

markstory · 2017-01-12T20:18:50Z

en/views/helpers/form.rst

    override the default HTTP method.

+Options for Form


Should this mention its for form creation

Fixed in current commit.

markstory · 2017-01-12T20:19:49Z

en/views/helpers/form.rst


 Changing the HTTP Method for a Form
 -----------------------------------

-By using the ``type`` option you can change the HTTP method a form will use::
+By using the ``'type'`` option you can change the HTTP method a form will use::


We don't generally include single quotes around key name as the inline code indicates that it is a key name.

I've removed the quotes around this word as indicated.
I think I've added quotes around pretty much around every key name; if I understand correctly I should remove them everywhere, right?
As a more particular case, should I remove them even in the enumeration lists (i.e. where we show a list of all the available key names, with their description; I'm asking that since in those places I guess they are meant to indicate what we should literally input in our code and might be helpful to leave no room for guessing for beginners.

My rationale for adding them was that some trivial key names such "type", "empty", "default", "value" etc. coincide with standard vocabulary words as well as with certain HTML attributes and I thought it would help disambiguate what we refer to, since it certain phrase constructions it can become fuzzy to tell what the author's intended meaning is (it might be more obvious for a veteran Cake user, but then again, they're not the main target audience of the manual as they need it less ).
Of course, if you think they need to go away, everywhere, I'll remove them all over the page where code examples aren't involved. Just making sure what I should do, for now.

markstory · 2017-01-12T20:36:47Z

en/views/helpers/form.rst

-will be used as a class name::
+When you set ``$options`` to a string it will be used as a class name:
+
+::


This should be folded with the line above.

Fixed in current commit.

markstory · 2017-01-12T20:37:35Z

en/views/helpers/form.rst

+
+For example::
+
+  // In Templates/Tickets/index.ctp


This needs to be indented in a multiple of 4.

Fixed in current commit.

markstory · 2017-01-12T20:37:45Z

en/views/helpers/form.rst

+
+.. code-block:: html
+
+  <form method="post" accept-charset="utf-8" action="/Rtools/tickets/delete/5">


This needs to be indented in a multiple of 4.

Fixed in current commit.

markstory · 2017-01-12T20:38:10Z

en/views/helpers/form.rst

-    echo $this->Form->input('password', [
-        'templateVars' => ['help' => 'At least 8 characters long.']
-    ]);
+  // Add a template with the help placeholder.


This needs to be indented in a multiple of 4.

Fixed in current commit.

markstory · 2017-01-12T20:38:15Z

en/views/helpers/form.rst

+
+.. code-block:: html
+
+  <div class="input password">


This needs to be indented in a multiple of 4.

Fix broken reST hyperlinks in Starting a Form section and for the wikipedia link. Change subsection title to Options for Form Creation. Remove quotes on 'type' key name in Changing the HTTP Method for Form section. Capitalize Modelname.fieldname across the whole page. Fix indenting of code block examples to always follow 4 spaces multiples in respect to page left margin or in respect to the paragraph hanging indent (when inside enumeration lists). Fix 2 other small formattings in the text.

admusin · 2017-01-13T12:19:29Z

Thanks @markstory for all the feedback; I know how tedious it can be to review somebody else's work.
In all fairness I checked the Documentation Formatting Guide but there was no mention about exact indenting rules to follow so I assumed that the PSR2 style of indenting was not mandatory for the docs. Should I had known it, I would have fixed all that stuff before committing and saved you all that extra work. If nobody does it before me, I'll try to add this mention to the Formatting Guide when I find a moment.

Your suggestion about smaller chunks of updates, was also duly noted. :)

I've fixed pretty much all that was indicated, in the current commit, save for the 2 questions, about quotes and code extra indentation inside enum lists; where I'll need your feedback, when you can find the time, in order to get it right.

inoas · 2017-01-13T15:28:30Z

Will that easily merge with #4559 ?

Edit: Thanks for doing this. I bit the bullet with too big PRs multiple times, but nevertheless this is very nice work.

antograssiot · 2017-01-13T17:52:15Z

@admusin you'll have to solve the conflicts for this to be mergeable.

antograssiot · 2017-01-13T17:54:39Z

I'Lloyd try to review it tonight or tomorrow also...

admusin · 2017-01-16T10:32:56Z

I've solved the conflicts and committed the solved version.
However, I'm still waiting for Mark's feedback on 2 of the points he raised and where I had asked some additional questions, when he'll find a moment, in order to finish the file.
Since we didn't clear those up yet, I'm not sure that it's ready to be merged yet, even if it doesn't show any conflicts now.

markstory · 2017-01-16T18:41:09Z

@admusin I can't find the 2 questions you asked. Where are they?

admusin · 2017-01-17T09:18:05Z

Hi @markstory ,

They are in the answers I wrote under your comments. Since now they display as "outdated", I suppose they're not popping up so much anymore and are easy to miss.

First:

+By using the ``'type'`` option you can change the HTTP method a form will use::

@markstory 5 days ago Member
We don't generally include single quotes around key name as the inline code indicates that it is a key name.

@admusin 4 days ago • edited Contributor

I've removed the quotes around this word as indicated.
I think I've added quotes around pretty much around every key name; if I understand correctly I should remove them everywhere, right?
As a more particular case, should I remove them even in the enumeration lists (i.e. where we show a list of all the available key names, with their description; I'm asking that since in those places I guess they are meant to indicate what we should literally input in our code and might be helpful to leave no room for guessing for beginners.

My rationale for adding them was that some trivial key names such "type", "empty", "default", "value" etc. coincide with standard vocabulary words as well as with certain HTML attributes and I thought it would help disambiguate what we refer to, since in certain phrase constructions it can become fuzzy to tell what the author's intended meaning is (it might be more obvious for a veteran Cake user, but then again, they're not the main target audience of the manual as they need it less ).
Of course, if you think they need to go away, everywhere, I'll remove them all over the page where code examples aren't involved. Just making sure what I should do, for now.

Second:

+  places, only the last group of inputs' values will be saved.
+
+    In this example, only the tertiary colors would be passed, and the
+    primary colors would be overridden:
@markstory 5 days ago Member

Why is this indented?
@admusin 4 days ago Contributor

This is indented because I've indented by one extra level in all options enumeration lists, the code examples along with their introductory phrases (be they short, such as: "E.g.", "For example" or longer such as the one you indicated here - In this example, only the tertiary...).

The rationale for this was that I found that some of the option enumeration lists lists (such as Options for Input, Common Options for Specific Input Types as well as Common Options for Select, Checkbox etc.) tend to occupy quite a bit of space and it becomes rather hard to differentiate between what's description/definition and what's example. I found that when landing in the middle of an options list it seems to be easier to visually scan through the list and "pick up" the definitions while ignoring the example if we're back just for a quick check (not a first read). I've fixed now the indenting to always be 4 spaces per indentation level.
Of course it might be only my subjective impression, and if you think they should stay at the same level of indentation I'll change back the indent for all code/output examples along with their introductory phrase.
Just let me know.

antograssiot · 2017-01-17T12:19:44Z

For point 1 you should remove all quotes where the value is already surrounded by backtick
or keep the quotes if it not a variable/value name and remove the backtick.
Sorry it seems to be widely used already in the doc

I'm not sure if it was mentioned before but I would suggest that you go with smaller changes for next contribution, to help review AND translators work.

antograssiot · 2017-01-17T12:27:36Z

en/views/helpers/form.rst

+    If you use a certain model field to generate multiple form fields via
+    ``input()``, and you want the same validation error message displayed for
+    each one, you will probably be better off defining a custom error message
+    inside the respective :ref:`validator rules<create-validators>`.


this label doesn't seems to exist and causes the build to break

@antograssiot , thanks for the feedback.
Yes, I've just realized that it's mistyped; the real label is "creating-validators".
I will fix it.

So, for the point above (about the quotes) what should I do in the end? I'm a bit fuzzy now, after your edit of your initial comment. :)

Indeed, one of the reasons why I went ahead and added them where they were missing, was the fact that they were already used in the document, on similar words (attribute names, element names, key names etc.) but not in a consistent fashion. So, I was trying to at least make the whole page look the same, not have the same word some times in quotes and some others not.
One other reason is that in most browsers, the simple back ticks yield a pretty mild result (they only change the font) but, visually, the results is not very easy to pick up so they might be missed. On top of that, if you have a word that is surrounded by quotes but not backticks, in the final result your straight quotes will be converted to curly quotes which kind of "alters" a bit their meaning; we tend to assume straight quotes exemplify a value as it should appear in code (e.g. a key name) whereas curly quotes might just mean you want to emphasize or cite something. But it might be just me.

Anyways, in short, if you guys think they should really go away, I can parse the whole page and eliminate them - I mean, even the ones that were already on the page - (save for code samples, of course), or else let me know.

antograssiot · 2017-01-17T12:43:32Z

for point 2, you should remove this extra indentation, here is the result i case you missed it:

instead of the actual

antograssiot · 2017-01-17T12:36:24Z

en/views/helpers/form.rst

+``$model``:
+
+* An ``Entity`` instance or an iterator will map to
+  `EntityContext <https://api.cakephp.org/3.3/class-Cake.View.Form.EntityContext.html>`_;


including those kind of links like that is a bad idea and will get outdated really quickly

We already have, since quite a while, on this page, a link to the API, inside the List Of Templates section. To be frank I found and still find it highly valuable, as I recently used it quite often. It's true it still points to the 3.2 version of the documentation but that part didn't seem to change in 3.3.

The thing is, that the enumeration list in the beginning of the page, as it is now, is of too little use to any first-comer without any pointer towards those classes; you won't know where these classes are.
In fact it's not obvious at first view even that they are classes for that matter; when I first arrived on the page I couldn't make heads or tails of this list and figured out that it's referring internal classes, from the small hint in the text of the 3rd option which is null, and then it took me a bit of search to actually find them.
The list tells us even less on what kind of options/arguments we could use to customize them.

The whole point of the links was to help other users avoid this hurdle and land on the corresponding API page then figure it out, themselves, from there, if needed.

I understand the argument about the API code maybe being changed in the future and the link becoming a bit stale; but I would argue that a user savvy enough to start creating custom contexts, will know to search for the last version of the API, starting from the corresponding page where s/he lands.
On the other hand if the API changes that much that these classes are completely removed or change names this section of the page will be probably rewritten anyways.

If you're adamant about removing them, I will, though.
Don't we have any other means of linking towards an API chapter where the link will seamlessly "migrate" along with the new API versions (let's say, as long as the "target section" API name doesn't change, even though its absolute URL might) ?

If we're linking to the API docs, do we need to duplicate all the options here? Seems redundant and makes the documentation harder to maintain, as we'll need to update both the links and options as they change.

@markstory
I've only added the options pertaining to Form Helper.
I didn't add any of the options that can be fed into the entity classes (that's why I added the links to their API pages) as I was thinking it may be too much. Just wanted to provide some doorway for anybody interested to know more about the entities, hence the added links.

Do you suggest that we should remove the links and enumerate the options of each entity instead? Or just simply drop the links?

As I said, I'm not against modifying the file and in the end I'll do what you guys request to make it fit neatly with the rest of the docs.

Given that the contexts don't have an book docs (as its not something the lay person has to interact with direclty) perhaps an API link is reasonable.

antograssiot · 2017-01-17T12:47:05Z

en/views/helpers/form.rst

+  provided then it will be autodetected based on the form context.
+  Valid values:
+
+  #. ``'get'`` - Will set the form method to HTTP GET.


not sure that we need an ordered list here

You're right, I'll change that.

antograssiot · 2017-01-17T12:52:34Z

en/views/helpers/form.rst


-  .. code-block:: html
+      Will output:


all those extra indentation needs to be removed

antograssiot

All extra text indentation and links to the api must be removed IMO

admusin · 2017-01-17T14:44:05Z

And yes, Mark already mentioned to me about submitting smaller chunks of changes in pull requests as they're easier to review and merge and I agree.

I can see better now, how this may trigger too many back and forth comments for a single request.

dereuromark · 2017-01-27T10:42:54Z

@admusin In general, try to make smaller chunks for PRs in the future. This will help to merge things faster.

So are we OK with those improvements as they stand currently?

admusin · 2017-01-27T11:05:13Z

@markstory
I've fixed all the requested things so far, except one on which I'll need your input.

We're talking about the quotes around some words.

To summarize:

On the original page (leaving code blocks aside) quotes are used together with backquotes on certain keywords that signify options names in Cake, but not all of them.
On some other words, that also signify Cake options, quotes are used without backqoutes, which actually transform them to curly quotes in the final form of the page.
These make the intended syntax, in the actual code, a bit random and confusing for a newbie (unless they check examples).
Sometimes words that elsewhere are surrounded by quotes or backticks and quotes are found bare in a different section of the page, even though they signify the same thing.

What I had done in the beginning was:

Adding quotes surrounded by backticks on all Cake option names that occur in text;
Adding just backticks on all names of: methods, HTML elements, HTML attributes;
Leave simple quotes (that will stay as curly quotes in the final doc) in a few places where it made sense and the intended meaning wasn't necessarily a property, key, method or attribute name but rather the common meaning of the word (e.g.: value, default).

Rationale
Quite a few of these same words (e.g. "type", "value", "default", etc.) are used in the text in various places as meaning different things:

Used as simple English words flowing naturally in the context of the phrase to convey meaning;
Used to mean HTML element or attribute names, mentioned when it makes sense in the phrase context;
Used to mean Cake keywords signifying method options' names;

In summary, hoping to clarify things I've used:

For simple English word cases --> no additional quoting or backticks (except in a few cases when I may have leaved the original quotes which are curly quotes on the web page, as it rather emphasized the meaning of the word).
For HTML elements and attributes mentioned in text --> just backquotes.
For Cake options mentioned in text --> quotes surrounded by backquotes (so that quotes don't become curly and the result looks exactly as in code).

Now, depending on what your own thoughts and preferences are (even if they're completely different from the above), I'll modify the page accordingly; just let me know how you'd like to format each of the 3 cases above.
Thanks.

admusin · 2017-01-27T11:08:15Z

Hi @dereuromark, sorry, I think I was writing my post above just in the meantime with yours.
Your input of my questions above would be just as welcome.

Once I know what you guys thinks is the better way to go about this, I'll make sure it gets that way and then it will be ready, from my point of view.
Thx.

dereuromark · 2017-03-11T09:52:14Z

Is there anything missing or good to go? //CC @markstory

follows cakephp#4598, cakephp#4829, cakephp#4834, cakephp#4913

[fr] Full sync of #4598

admusin added 13 commits December 16, 2016 13:21

Add line breaks in note of Creating Form Inputs

b7fc2bb

Add line breaks in the note present inside Creating Form Inputs

Recheck and fix non-code lines longer than 80 chars.

43254b6

Fix indenting for some notes.

Revert indenting for all code blocks (except inside enum lists) towar…

33d33a7

…ds original Small indenting fixes.

markstory requested changes Jan 12, 2017

View reviewed changes

Merge branch '3.0' into 3.0

b9d1f2d

antograssiot reviewed Jan 17, 2017

View reviewed changes

antograssiot suggested changes Jan 17, 2017

View reviewed changes

Merge branch '3.0' into 3.0

1aa41fa

ravage84 added the Docs Missing label Mar 8, 2017

ravage84 added this to the 3.x milestone Mar 8, 2017

admusin added 2 commits March 8, 2017 11:06

Correct too short underline for title on line 676

d008b53

Fix 2 title underlines that were too short

dd479f1

markstory merged commit 09c9e73 into cakephp:3.0 Mar 11, 2017

okinaka added the needs-ja-translation label Mar 25, 2017

okinaka added a commit to okinaka/docs that referenced this pull request Apr 20, 2017

[ja] update form.rst.

508692b

follows cakephp#4598, cakephp#4829, cakephp#4834, cakephp#4913

okinaka mentioned this pull request Apr 20, 2017

[ja] update form.rst. #4914

Merged

okinaka removed the needs-ja-translation label Apr 20, 2017

okinaka added a commit to okinaka/docs that referenced this pull request Apr 22, 2017

[ja] update form.rst.

557d3c2

follows cakephp#4598, cakephp#4829, cakephp#4834, cakephp#4913

okinaka added a commit to okinaka/docs that referenced this pull request Apr 23, 2017

[ja] update form.rst.

3f36299

follows cakephp#4598, cakephp#4829, cakephp#4834, cakephp#4913

HavokInspiration added the needs-fr-translation label Jun 7, 2017

HavokInspiration added a commit that referenced this pull request Jun 26, 2017

[fr] Start updating the FormHelper page following #4598

6448af1

HavokInspiration added a commit that referenced this pull request Jun 26, 2017

[fr] Continue working on the #4598 translation

98a6301

HavokInspiration added a commit that referenced this pull request Jun 27, 2017

[fr] Continue translatin #4598

54ab742

HavokInspiration added a commit that referenced this pull request Jun 28, 2017

[fr] Another round for #4598

63c853e

HavokInspiration added a commit that referenced this pull request Jun 30, 2017

[fr] Continue #4598

cf40642

HavokInspiration added a commit that referenced this pull request Jun 30, 2017

[fr] Continue #4598

8ec2522

HavokInspiration added a commit that referenced this pull request Jun 30, 2017

[fr] Continue #4598

d3ebfd2

HavokInspiration added a commit that referenced this pull request Jul 1, 2017

[fr] Continue following #4598

6a95bd9

HavokInspiration added a commit that referenced this pull request Jul 2, 2017

[fr] Finish translating #4598

4e5fc01

HavokInspiration removed the needs-fr-translation label Jul 2, 2017

HavokInspiration mentioned this pull request Jul 2, 2017

[fr] Full sync of #4598 #5069

Merged

HavokInspiration added a commit that referenced this pull request Jul 2, 2017

[fr] Finish translating #4598

1023760

markstory added a commit that referenced this pull request Jul 2, 2017

Merge pull request #5069 from cakephp/3.0-fr-formhelper

a3cc703

[fr] Full sync of #4598


		.. code-block:: html

		<form method="post" accept-charset="utf-8" action="/Rtools/tickets/delete/5">

Add missing options, add method arguments lists with descriptions, examples and definitions #4598

Add missing options, add method arguments lists with descriptions, examples and definitions #4598

Uh oh!

Conversation

admusin commented Jan 12, 2017

Uh oh!

markstory left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

admusin Jan 13, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

admusin commented Jan 13, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

inoas commented Jan 13, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

antograssiot commented Jan 13, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

antograssiot commented Jan 13, 2017

Uh oh!

admusin commented Jan 16, 2017

Uh oh!

markstory commented Jan 16, 2017

Uh oh!

admusin commented Jan 17, 2017

Uh oh!

antograssiot commented Jan 17, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

antograssiot Jan 17, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

admusin Jan 17, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

antograssiot commented Jan 17, 2017

Uh oh!

Choose a reason for hiding this comment

admusin Jan 13, 2017 •

edited

Loading

admusin commented Jan 13, 2017 •

edited

Loading

inoas commented Jan 13, 2017 •

edited

Loading

antograssiot commented Jan 13, 2017 •

edited

Loading

antograssiot commented Jan 17, 2017 •

edited

Loading

antograssiot Jan 17, 2017 •

edited

Loading

admusin Jan 17, 2017 •

edited

Loading

admusin Jan 17, 2017 •

edited

Loading

admusin Jan 18, 2017 •

edited

Loading

admusin commented Jan 27, 2017 •

edited

Loading

admusin commented Jan 27, 2017 •

edited

Loading