rest/forms-brainstorming: Difference between revisions
Jump to navigation
Jump to search
(→Forms Brainstorming: Proposal B) |
|||
Line 3: | Line 3: | ||
This page collects ideas from [[forms-examples]] how to best encode form data into a microformat | This page collects ideas from [[forms-examples]] how to best encode form data into a microformat | ||
DETH | == Proposal A: DETH - Dictionaries Encoding/Transmitting HTML == | ||
== Rules (Strawman) == | === Rules (Strawman) === | ||
# Only use [http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_sformsmodule XHTML Basic Forms] Module | # Only use [http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_sformsmodule XHTML Basic Forms] Module | ||
Line 14: | Line 14: | ||
# Always place ''submit'' and ''reset'' outside grouping | # Always place ''submit'' and ''reset'' outside grouping | ||
== Questions for further research == | === Questions for further research === | ||
# How to specify whether a field is optional or required? | # How to specify whether a field is optional or required? | ||
== Patterns == | === Patterns === | ||
=== Anchor Design Pattern === | ==== Anchor Design Pattern ==== | ||
<a class="deth" href="http//somesite.com/prog/adduser">label</a> | <a class="deth" href="http//somesite.com/prog/adduser">label</a> | ||
=== Forms Design Pattern === | ==== Forms Design Pattern ==== | ||
<form class="deth" action="http://somesite.com/users" method="post"> | <form class="deth" action="http://somesite.com/users" method="post"> | ||
Line 81: | Line 81: | ||
} | } | ||
} | } | ||
== Proposal B: REST-oriented process == | |||
From [Kyle Cordes], for the discovery of the parameters: | |||
* You discover the URL of a service by some means. | |||
* You GET that URL, which returns an HTML form. | |||
* The HTML form describes where to POST to invoke that service, and what | |||
parameters can be passed in that POST. In some cases, it will use | |||
<selects>s to describe what options are valid for a parameter. | |||
* In most cases, the form will be interspersed with human readable text, | |||
to explain the meaning of the parameters (a machine-understandable way | |||
to explain parameter meaning, sounds like an AI problem...) | |||
* You (the user of a web browser, or a piece of software | |||
programmatically using the server) populate the parameters and POST them | |||
to the URL you discovered via the form. | |||
* You get back a response, which might be an error message about a | |||
parameter problem, or might be a respresentation of the "answer". | |||
== See Also == | == See Also == |
Revision as of 23:01, 3 November 2005
Forms Brainstorming
This page collects ideas from forms-examples how to best encode form data into a microformat
Proposal A: DETH - Dictionaries Encoding/Transmitting HTML
Rules (Strawman)
- Only use XHTML Basic Forms Module
- Must use action with appropriate URI (no scripts)
- Recommend: use a label with every input
- Make the for of the label match the id of input
- Group label with input using
- Always place submit and reset outside grouping
Questions for further research
- How to specify whether a field is optional or required?
Patterns
Anchor Design Pattern
<a class="deth" href="http//somesite.com/prog/adduser">label</a>
Forms Design Pattern
<form class="deth" action="http://somesite.com/users" method="post"> <dl> <dt><label for="firstname">First name:</label></dt> <dd><input type="text" id="firstname" /> </dd><dt> <label for="lastname">Last name:</label></dt> <dd><input type="text" id="lastname" /> </dd><dt>Sex</dt> <dd><input type="radio" name="sex" value="male">Male</input> <input type="radio" name="sex" value="female">Female</input> </dd><dt>Travel</dt> <dd> <input type="checkbox" name="travel" value="car">Car</input> <input type="checkbox" name="travel" value="bike">Bicycle</input> </dd><dt> <label for="age">Age:</dt> <dd> <select> <option val=0>< 18</option> <option val=18>18-64</option> <option val=65>65+</option> </select> </dd><dt> <label for="description">Description:</label></dt> <dd><textarea id="description">Default text</textarea> </dd> </dl> <input type="submit" value="Send" /> <input type="reset" /> </form>
Sample Python Binding
order=[ "firstname","lastname","sex",'"travel", "age","description" ] dict={ "@@tag":"form", "@action":"http://somesite.com/users/", "@class":"deth", "@enctype":"application/x-www-form-urlencoded", "@method":"post", "@@order":order, "firstname":"First name:", "lastname":"Last name:", "sex":{"@type":"radio", "male":"Male", "female":"Female"}, "travel":{"@type":"checkbox", "car":"Car", "bike":"Bicycle"}, "age":{"@@body":"Age:", "@type":"select", "0":"< 18", "18":"18-64", "65":"65+" }, "description":{ "@@body":"Description:", "@type":"textarea", "@value":"Default text" } }
Proposal B: REST-oriented process
From [Kyle Cordes], for the discovery of the parameters:
- You discover the URL of a service by some means.
- You GET that URL, which returns an HTML form.
- The HTML form describes where to POST to invoke that service, and what
parameters can be passed in that POST. In some cases, it will use <selects>s to describe what options are valid for a parameter.
- In most cases, the form will be interspersed with human readable text,
to explain the meaning of the parameters (a machine-understandable way to explain parameter meaning, sounds like an AI problem...)
- You (the user of a web browser, or a piece of software
programmatically using the server) populate the parameters and POST them to the URL you discovered via the form.
- You get back a response, which might be an error message about a
parameter problem, or might be a respresentation of the "answer".