Why in-place editing of forms displayed with the displayed version instead of on-the-fly visualization?

Question

Is there any specific reason why most of all implement editing in the form of the shown "display" div and the hidden "editing" div, which turn on and off when someone clicks on the corresponding "edit" button?

<div id="title"> <div class="display"> <h1> My Title </h1> </div> <div class="edit"> <input type="text" value="My Title" /> <span class="save_edit_button"></span> <a href="#" class="cancel_edit">Cancel</a> </div> </div> 

Wherever I look, I see that in-place editing is basically handled this way. This approach, of course, makes sense when you view all types on the server side and deliver them to the client. However, with clean AJAX applications and frameworks like backbone.js, it seems like we could make our code much DRY by visualizing the edit form elements in place if necessary, perhaps even creating a factory method that determines which form elements to render. . eg.

• element H1 with class "title" is replaced by <input type="text" />
• the range with the class "year_founded" is replaced by <input type="number" min="1900" max="2050" />
• a range with the class "price" is replaced with an input with the corresponding mask, so that only enter prices.

Is this practice rendering all the elements of an in-place edit form a historical legacy left after the pages were displayed on the server side?

Given the flexibility and power we have with client MVC infrastructures such as Backbone.js, is there any reason not to create and insert form elements on the fly if necessary using the factory method? Something like that:

HTML

 <div id="description"> Lorem ipsum dolar set amit... </div> <span class="edit_button"></span> 

Backbone.js View

 events: { "click .edit_button": "renderEditInPlaceForm", }, renderEditInPlaceForm: function:(e) { var el = $(e.currentTarget).previous(); var id = el.attr('id'); var value = el.text(); var tagName = el.tagName(); var view = new editInPlaceForm({ id: id, type: tagName, value: value }); $("#id").html(view.render().el) }, 

Where editInPlaceForm is a factory that returns the corresponding type of the edit form element in place based on tagName. This kind of factory also manages all its own logic to save editing, cancel editing, submit requests to the server and retransmit the corresponding source element that has been replaced with the .html () function?

It seems to me that if we use this approach, we could also make the <span class="edit_button"></span> "on the fly" buttons based on user rights, for example:

 <h1 id="title"> <%= document.get("title") %> </h1> <% if (user.allowedToEdit( document, title )) { %> <span class="edit_glyph"></span> <% } %> 

where the allowedToEdit function in the user model takes the model and attribute as arguments.

Answer 1

This is an interesting idea. The devil is in the details.

While your simple example easily displays as an editable form on the fly, things quickly become more complicated when working with other data types.

For example, suppose my edit form requires the user to select a value from the select list. In the display form, I can simply display the user's selection, but for the edit form I will need these other available options. Where can I hide them on the display? Similar problems exist for checkboxes, radio lists ...

So, maybe we should think about rendering the editing form, and then extract our screen from it?

Answer 2

After 5 basic applications, I came to the same thoughts.

When it's complicated, you have forms to display the relationship between user data, but in simple cases you just need input , select , checkbox over h1 , div or span

Now I am looking for a jQuery plugin for simple editing without using ajax. jQuery, but not Backbone, because I don't want to be tightly coupled with Backbone for such a small thing.

Most likely, it will be my own jQuery + Synapse plugin http://bruth.github.com/synapse/docs/ .

Syntax for model binding and jQuery for input placement