Yelotofu

Yelotofu ~ “In building standards compliant sites we are creating a better Web for the future.”

Labs: UI inlineEdit

Tags: , , , , , , ,

After my last tutorial on building a simple inlineEdit plugin I converted the concepts into a UI widget. It's now sitting in labs for you to use, pick apart and devour:

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

If you inspect the source code you will notice the structure is quite different. It's actually pretty much the same functionality wise but I have separated each piece into smaller chunks. This makes it easier to extend in future (I plan to write more on ways to extend UI widgets in another post).

Here's a quick peek at the features:

  • Basic inline editing - click, edit, save
  • Ability to save on pressing ENTER key
  • Cancel by un-focussing the input or clicking cancel
  • ThemeRoller ready
  • Customisable empty placeholder
  • Save and Cancel callbacks
  • Cancelable Save callback (so you could script a cancel action)

As usual please feedback and help improve this widget either by commenting here or on the InlineEdit design & planning page

Enjoy!

2nd Sep 2009, 1:32 am PDT | RSS 2.0 | Comment | Trackback

Similar Posts

« Tip: Obtaining Request Parameters in Zend_View
Zend Server CE and Snow Leopard Problem »

3 Comments

  1. By Daniel Crenna at 9 Sep 2009 1:15 am PDT

    Hello,

    This is a great concept for a jQuery UI plugin, but I ran into a few glitches I’m trying to solve.

    - The “ENTER” key doesn’t behave like “Save” as the feature list suggests, in IE it posts the dynamically constructed form, in FF it doesn’t do anything. This true of the demo as well.

    - The demo also doesn’t save any values you enter, I’m not sure if that’s because you’re supposed to provide your own save implementation in a hook, and if so, can the demo show a simple changing of values on the client-side? It looks to me like the intention is to change the value of the .editable element, but this is not happening.

    - It appears the widget intialization code takes the value of the .editable element on init, but in my case that may have changed dynamically before inline editing takes place. I think this can be solved by changing the “_uiInlineEditHtml” function to use “this.element.text();” rather than “this.value()” since this will grab the options value that was set on load, and not necessarily what the element’s value is now.

  2. By caphun at 9 Sep 2009 2:24 am PDT

    Hi Daniel,

    Thanks for the analysis. You’re right about hitting the ENTER key, looks like I broke something in a recent change.

    The Save callback is where you should put your save logic. The idea is that this widget simply enhances a plain text area to allow editing. Whether one decides to do an Ajax post or save values to a hidden field is up to the developer to decide in the Save callback. A demo to show this is a good idea. I’ll give that a think.

    this.value() is used to centralize getting/setting the current value. The value is set on init and also set whenever a change is made. Additionally the benefit of being a UI widget is the options value could be changed programmatically at anytime: 

    $('#editable').inlineEdit('option', 'value', 'My Value');

  3. By caphun at 9 Sep 2009 3:37 am PDT

    Just fixed the demo. Should be working properly now.

Leave a Reply

* marks a required field.



(this will not be published)