rest/forms-brainstorming: Difference between revisions
Jump to navigation
Jump to search
(revert to previous changed by OlaBerg ---> vandalism) |
|
(19 intermediate revisions by 14 users not shown) | |
(No difference)
|
Latest revision as of 16:11, 16 September 2010
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?
- Suggestion: the label contains a * ?
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".
[OlaBerg] says: This is exactly what I do, and it works great! In fact, I use it both for POST-API and GET-API. A set of forms defines a REST-ful API.