Adding placeholder to text element type.
Running all tests per file.
Make event binding optional with submitEvent: false.
This allows event binding to be left to a framework like Backbone or rendering of the form into a descendant of the form element.
Do not use jQuery's attr method to get data-idx attribute.

In some context, it fails inexplicably (the jQuery object is
correctly initialized, the attribute is present); instead
use .get(0).getAttribute().
We could've used .data(), but this seems a better alternative
that lies on things that will not move soon.
file-transloadit: fix for results from steps other than ":original"

The "file-transloadit" field allows one to use arbitrary Transloadit
templates that can run any number of steps. The code assumed that the
final file would always be generated by the ":original" step which
may not always be the case.

Note JSON Form expects the upload to generate one and only one file.
It will pick up the first image that appears in the results otherwise,
but there is no guarantee that this image is the right one.
Added support for most HTML5 input types (date, email, tel...)

The following HTML5 input types may now be specified in the "form"
section of a JSON Form object:

- date
- datetime
- datetime-local
- email
- month
- number
- range
- search
- tel
- time
- url
- week

Input types such as "text", "password", "hidden", "checkbox", "radio",
"button", or "submit" work as before.

The "range" input type uses the JSON Schema properties "minimum",
"maximum", "exclusiveMinimum" and "exclusiveMaximum" to set the
boundaries of the range input field. The description of the field
in the "form" section may also impose a "step" different from 1 if
needed, but note that step is not enforced when the form is submitted.

The code has no fallback mechanism for the case when the Web browser
does not support these additional types. The input fields are just
rendered as regular text input fields in that case. In particular,
there is no guarantee that the submitted value will actually match
the constraints of the specified type (user may well enter
"hello world" in a "date" field on browsers that do not support
that input field type).
Field size dropped from HTML template, new "inputSize" param (#30)

JSON Form produced input types that all had the class "input-xlarge",
whereas it should not make any assumption on the styles and dimensions
of the input fields. The "input-xlarge" class is no longer added to
input fields by default.

To achieve the same effect, define an "inputSize" property in the
description of the input in the "form" section. If you want to apply
the same sizing class to all input fields, set that property in a
global "params" property of the JSON Form object:

{
  "schema": {},
  "form": [],
  "params": {
    "inputSize": "input-xlarge"
  }
}

PS: for some reason, the "range" input field did not make it to
previous commit. This commit also introduces the "range" input (#27)
Added support for "required", "maxLength" and "readonly" (#32)

JSON Form now converts JSON Schema properties "required" and
"maxLength" into the appropriate attributes on the input field.

For the "required" property, JSON Form also adds a "jsonform-required"
class to the field container's "<div>" and a "jsonform-hasrequired"
class to the "<form>" tag. The former allows one to flag required
fields easily with a CSS property such as:

  .jsonform-required > label:after {
    content: ' *';
    color: red;
  }

The latter allows one to add a legend at the end of the form, e.g.
with a CSS property such as:

  form.jsonform-hasrequired:after {
    content: '* Required field';
    display: block;
    color: red;
    padding-top: 1em;
  }

JSON Form also supports the "readonly" property when it is set in the
definition of an input field in the "form" section of a JSON Form
object (as opposed to in the schema since "readonly" simply does not
exist in JSON Schema).
Renamed "inputSize" param into "fieldHtmlClass"

The property may be used to specify classes that have nothing to do
with the size of the final input field.
Merge branch 'master' of git://github.com/globocom/jsonform into globocom-master

Conflicts:
	lib/jsonform.js
Added example usage for the "placeholder" property (#35)
Merge pull request #40 from lrowe/master

Make event binding optional with submitEvent: false.
Added "jsonform-readonly" and "jsonform-disabled" to container (#47)

The mechanism is the similar to that used for the "required" property:
if the input field is marked as readonly or disabled, the
corresponding attribute gets added to the input field and its root
container "<div>" is marked with a "jsonform-" class to ease styling.
Fixed code that could make "hasRequiredFielfd" function crash
Fix validation when using wysihtml5 in chrome.

Chrome raises an error if a textarea with a required attribute is hidden.
Added support for "uri" and "email" format validation in JSV

Schema keys of type "string" may define an additional "format"
property set to "uri" or "email". These constraints were ignored
by the JSON Schema validator. They are now enforced using regular
expressions.

Note the "uri" really means absolute uri. Relative URIs are rejected.
The scheme may be just about anything.
Updated URI format to only accept HTTP(s) URIs

Note this is a willful deviation from the JSON Schema spec which does
not restrict URIs to HTTP(s) URIs. In practice, most if not all URIs
requested in a form are HTTP(s) URIs, so the restriction makes sense
not to force JSON Form users to specify their own regular expression
to restrict the scheme.
Set values to false for unset checkboxes and radio buttons
Dropped "required" attribute for checkbox fields

In JSON Schema, defining a boolean schema key as "required" means
that the property must appear in the generated object. Whether it
is true or false does not matter.

In HTML5, the "required" attribute on a checkbox means "the checkbox
must be checked to proceed". That's not really the same meaning.

JSONForm does not add the "required" attribute to a checkbox anymore
to remain compliant with the definition of "required" in JSON Schema.
As a matter of fact, since falsy values are now set in the generated
object, the "required" constraint on a boolean schema key is always
enforced.
Non empty object when a nested empty number was submitted (#38)

Given an object defined with a "number" property, form submission
always generated the path that led to that "number" property in the
resulting object, even when the user did not enter any actual number
in the form.

Paths should only be created when there are actual non empty
properties to create.