option to go to a separate page with its own form. Sure, it’s more coding, but
think about the possible scenarios:- A user doesn’t have a browser that supports contenteditable.
- A user is using a modern browser but still disabled JavaScript simply
because he doesn’t like JavaScript (it happens more often than you’d
think). - A user is behind firewall software that filters out JavaScript. Believe it or
not, such firewalls exist and they make life miserable for both users and
developers.
When it comes down to it, making a form that does a POST request to the same
action that handled the Ajax update makes the most sense. How you do this
is up to you, but many frameworks let you detect the type of request by
looking at the accept headers to determine whether the request came from a
regular POST request or an XMLHttpRequest. That way, you keep the server-side
code DRY.^8 We’ll hide the link to this form if the browser supports contenteditable
and JavaScript.So, we create a new page called edit.html, and code up a standard edit form
that posts to the same update action that our Ajax version uses.html5_content_editable/edit.html
<!DOCTYPEhtml>
<htmllang="en-US">
<head>
<metacharset="utf-8">
<title>EditingProfile</title>
<linkrel="stylesheet"href="stylesheets/style.css">
</head>
<body>
<formaction="/users/1"method="post"accept-charset="utf-8">
<fieldsetid="your_information">
<legend>YourInformation</legend>
<ol>
<li>
<labelfor="name">YourName</label>
<inputtype="text"name="name"value=""id="name">
</li>
<li>
<labelfor="city">City</label>
<inputtype="text"name="city"value=""id="city">
</li>- DRY stands for “Don’t Repeat Yourself” and is a term coined by Dave Thomas and
Andy Hunt in The Pragmatic Programmer [HT00].
report erratum • discussIn-Place Editing with contenteditable • 63
Download from Wow! eBook <www.wowebook.com>