InlineEdit

Page history last edited by Oskari Grönroos 6 mos ago

type: widget

release: 0.0

priority: very low

status: in planning

documentation: N/A

demo: http://jquery-ui.googlecode.com/svn/branches/labs/inlineedit/demo.html

1 - Description:

This plugin allows for a common Web 2.0 interaction pattern where a user clicks (multiple other variations exist; double click, presses button or double clicks or pressed a link/button) on a title or block of text and the content is transformed into an editable form element. The changes can be saved via AJAX on a range of events: keyUp, change, Blur, or when a Save button is pressed. A Cancel button or link is also an optional element to undo the changes.

When activating an element, the widget can either turn the specific element, a set group of elements (grouped by div or fieldset[?]) or the entire page's elements into form elements.

Save and Cancel buttons can function for every individual element, for a set group of elements (grouped by div or fieldset[?]) or the entire page's elements. The location for the Save and Cancel buttons must be defined by a div or a span. The widget must take notice if the user tries to close the browser window or tab before saving the edited content.

Stuart Loxton created a simple edit in place demo with a few typical options:

http://stuartloxton.com/demos/uiEdit (link is broken!)

Jeditable looks really good and full featured:

http://www.appelsiini.net/projects/jeditable

2 - Visual Design:

(Initial wireframe mockup, followed by more detailed designs of the various configurations, options and states.)

3 - Functional Specifications/Requirements:

(Detailed description of how the script will be structured: defaults, options, architecture, extensibility, etc.)

4 - Markup & Style:

4.1 Initial markup examples

(Pre-enhanced HTML markup structure that will be transformed into the final widget. There may be multiple possible HTML markup options per widget: for example, for a slider, radiobuttons, inputs or selects could all be used. )

4.2 Recommended transformed HTML markup

(The HTML markup structure and classes that will be used by the scripts in the enhanced version)

4.3 Accessibility recommendation

(Detailed recommendations for ARIA, HTML markup, CSS and javascript that will contribute to universal access and full section 508 accessibility for screen readers, mobile devices and any other devices)

4.4 CSS & Theme

(Description of the CSS classes to be used for all states, how custom theming and Themeroller support will work.)

5 - Latest version of plugin:

(Link to the latest version in the jQuery UI trunk here)

6 - Open issues being discussed

(Use this area to place things that we're hashing out like features and options we're not sure we should include, questions about how this fits into UI and relates to other widgets and utilities, known problems, whether features should be broken across multiple releases, etc.)

Comments (9)

One thing that stands out about writing this plugin is who handles the saving of the data. Should the plugin handle it via synced input fields (which it can handle already), AJAX posts to another page OR should the user handle the saving of a field via actions such as editSave, editStop, etc. I would go for the user handling it as better as it allows for more customisation in situations that need it. E.g, field may not need to be saved on external site but instead set in a cookie. Handling all situations is a possibility but might lead to a large vague bloated plugin.

I agree that just exposing events that the user can react to however they want is the way to go. If there is enough interest in a specific method for saving data, we can add that in later.

i've gotten a lot of mileage out of greg weber's ui table edit plugin
http://gregweber.info/projects/uitableedit
which exposes 3 callbacks
mousedown, dataVerify, editDone and i added a 4th, "activated," which is called after the input elements have been created (for binding autocomplete, etc)
these would seem to be the critical moments in the interction.

Just uploaded a slightly newer version, the validation option now accepts either a regular expression or a function. Also I've quickly added 3 events editCancel, editFinish and editStart. For cancelled inputs, whenever an editing session is finished and when one is activated. The demos don't have any of these in however you can test by using firebug by just typing: $('li').bind('editFinish', function() { console.log(this, 'finished editing'); });

Any extra events on the input (e.g. keyDown, keyUp, mouseDown can be binded inside of the editStart event), events such as mouseDown can be binded to the editable target as per normal fashion.

The current version seems to have issues with Chrome after an editing of any field is complete.

I have made my own implementation using contenteditable attribute. It's very simple widget, and works primarily based on event callbacks. As discussed, I also find that this provide with most of the necessary functionalities of an inline editor without having bloated features (and like Scott said, when common features will be requested, then they might be integrated into the widget). The demo site is plain and mostly empty, but it serves it's purpose, and the code is easy to read and understand.

http://mind2soft.com/labs/jquery/editable/demo/#demo

Hi Yanick - The expandable div example works great but the top example with a span has odd behavior when I add line breaks -- it seems to create a new text input for each line and when I focus back in, the script highlights the whole block of inputs so it's sort of broken. This is in Chrome/Mac.

yeah, I have noticed that. This is because the top example is a SPAN element. I guess it could be possible to switch into an auto-sizing element that would look more like the bottom example. Or perhaps wrapping the editable element inside a div and apply CSS classes to make it more homogeneous (and making sure that the edited container does not display any border, even when in focus). Note that I wrote that in less than two hours, but I thought I would present an INPUT-less in place editor that follows quite all that has been said so far :)

plus, if you press ctrl+B, ctrl+I, ctrl+U it changes the basic formatting (in chrome anyway), so it's definitely a plus here (it could be prevented if the user wants it)

You don't have permission to comment on this page.