 |
|
 |
 |
|
|
 
John Reynolds's Blog
«News from a Parallel Universe: JSF and Tapestry project leads agree on future course |
Main
| Why is so much software so bad? »
Pragmatic Web Forms: WebForms2Posted by johnreynolds on February 20, 2005 at 05:31 PM | Comments (10)I recently came across a discussion of WebForms2, and after checking out the links I've come away pleasantly optimistic that building form-centric web applications is about to get simpler.
The WebForms2 proposal is a product of WhatWG (the Web Hypertext Application Technology Working Group). WhatWG is a loose consortium of browser manufacturers who have banded together to make the development of web applications easier. Rather then pursuing proprietary browser-specific solutions, they are developing technologies that can either be used by existing browsers, or can be implemented by all future browsers. Proprietary is a dirty word with this group. The WebForms2 proposal specifically targets the question: "How can we make it easier for developers to create sophisticated web forms?" For example, how can we make it easier for an HTML author to add an input field to a form which will only accept a date that falls within a specific range? WhatWG’s answer is not new technology; their answer is to define standard labels that add type and validation information to existing HTML tags and to distribute JavaScript libraries that utilize these labels. Here's how it works: When a form is submitted the WebForms2 JavaScript parses the DOM, looking for the standard labels. If an <input> element is encountered that contains an attribute "type=number", then the input text will be checked to verify that it is numeric. If the parser encounters additional attributes such as "min=" and "max=" then further validation will kick in. This is really a quite simple technique that has been used for years... but now it's being "standardized". Here’s an example from the WebForms2 documentation (I have underlined some of the standard labels):
<form action="..." method="post" onsubmit="verify(event)">
<p>
<label>
Quantity:
<input name="count" type="number" min="0" max="99" value="1" />
</label>
</p>
<p>
<label for="time1"> Preferred delivery time: </label>
<input id="time1" name="time1" type="time" min="08:00" max="17:00" value="08:00" /> —
<input id="time2" name="time2" type="time" min="08:00" max="17:00" value="17:00" />
</p>
<script type="text/javascript">
function verify(event) {
// check that time1 is smaller than time2, otherwise, swap them
if (event.target.time1.value >= event.target.time2.value) {
// ISO 8601 times are string-comparison safe.
var time2Value = event.target.time2.value;
event.target.time2.value = event.target.time1.value;
event.target.time1.value = time2Value;
}
}
</script>
</form>
Some XForms proponents argue that the WebForm2 approach is just a band-aid since it only handles simple forms. That's a valid concern, but sometimes a band-aid is all that you need. WebForms2’s approach is limited, but it should work on any browser that supports JavaScript DOM navigation.
Why does this matter to Java developers? If you use any of the Java Web Component Frameworks (such as JSF, Tapestry, and Echo) then WebForms2 should be on your radar screen. For example: What would be the result of mixing and matching Tapestry components and WebForms2 labels on the same page? On a very basic level, there’s no relationship between Tapestry components and WebForms2 labels. WebForms2 is strictly client-side behavior, and won't have any effect on Tapestry’s server-side processing. The only possible collisions are between the text that Tapestry injects on the page and the labels recognized by WebForms2. On a deeper level, for the Web Page and Web Component authors the implications of WebForms2 on Tapestry become apparent at design time. Design of a Tapestry page begins with the creation of an HTML template. Labels are then added to HTML elements to “transform them” into Tapestry components (all HTML elements with the jwcid label are replaced by Tapestry generated output). With WebForms2 on the scene, HTML Authors will be much more likely to incorporate WebForms2 labels within thier HTML tags. If Tapestry components don’t recognize the standard WebForms2 labels and map them properly, key information might be overlooked. If WebForms2 becomes prevalent takes off, it will make sense to re-work some of the Tapestry components. I'm not familiar enough with writing JSF components to know if WebForms2 will have a similar impact. The "IDE centric" nature of JSF application development could very likely make any potential issues moot. Any decent IDE can easily "pick out" the WebForms2 labels when an HTML file is imported, and map this information for any JSF equivalent components.
In any case, I am pleased with WhatWG's WebForms2 proposal and approach. They have come up with a pragmatic solution (both technically and politically) for a well understood problem. Adoption of WebForms2 requires very little effort from Web Page Authors, doesn't require buy-in from browser vendors, and promotes simplified HTML authoring. Simplifying things is good. Update: Mozilla and Opera published the following: Position Paper for the W3C Workshop on Web Applications and Compound Documents. Their philosphy is summed up by the following statement: "Any solution that cannot be used with the current high-market-share user agent without the need for binary plug-ins is highly unlikely to be successful." Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
CommentsComments are listed in date ascending order (oldest first) | Post Comment
| |
 java.net RSS Feeds
|
