Skip to content

Fix documentation typo #469

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 11, 2015
Merged

Fix documentation typo #469

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions docs/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -417,7 +417,7 @@ error code, so to specify a error message you also need to use.
[
{
key: 'name',
validationMessages: {
validationMessage: {
'noBob': 'Bob is not OK! You here me?'
},
$validators: {
Expand All @@ -441,7 +441,7 @@ a promise that resolves or rejects.
[
{
key: 'name',
validationMessages: {
validationMessage: {
'noBob': 'Bob is not OK! You here me?'
},
$asyncValidators: {
Expand All @@ -467,7 +467,7 @@ Form defaults in schema
Its recommended to split presentation and validation into a form definition and a json schema. But
if you for some reason can't do this, but *do* have the power to change the schema, you can supply form
default values within the schema using the custom attribute `x-schema-form`. `x-schema-form` should
be a form object and acts as form definition defaults for that field.
be a form object and acts as form definition defaults for that field.

Example schema.
```js
Expand Down