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".