I’m very happy to announce the latest update to EditInPlace, version 0.3.0. There is a lot to cover, so let’s dive right in.
First off a little history. I’ve rewritten this library more than a few times in an effort to find “the right way” to do things in Javascript. Since then I’ve come to the conclusion that there isn’t anything even close to a right way in Javascript, and people complain about Perl. At any rate, while I don’t consider the approach I used for 0.3.0 to be perfect, I do think that it will prove stable enough to not need major/complete re-writes in the future. (Yes I realize that I’ve now cursed myself to a re-write in the future.)
If you want to see it in action go check out the example page. Viewing the HTML source should be obvious enough for those of you who want to try it out right away. For those of you using previous versions of EditInPlace this one should be a drop in upgrade except for some of the default CSS class names.
So what’s new in 0.3.0?
- A big item was fixing the bug where the saving text was editable. You can read about the details of what it took to fix this in Javascript Events With Prototype. Thanks to all those who pointed out that problem.
- Andrew Kelly suggested an option to display the edit form on a double click instead of a single click. The default is still single click but double click can be used by setting the option ‘click’ to ‘dblclick’.
- Jeff Nunn suggested an option to have the text to edit selected when the edit form is displayed. The default is to not do this, but you can turn it on by setting the ‘select_text’ option to true. My initial tests show that this doesn’t seem to work in Safari though.
- Default options are easy to over ride now.
- More options are available, including all of the CSS class names, the empty edit string, the saving message and the failed to save message.
- Better documented code in the EditInPlace.js source code.
Jonathan Snook recently discussed Improving Edit in Place and I’ll address his points. Before I do that though you should know that version 0.3.0 was already wrapped when he posted his comments.
- CSS class names – You can set your all of your own CSS class names now.
- Jonathan does have a point though about the layout not being flexible. I’ve added this to my todo list for EIP and I’m already looking a different methods of making the form layout user definable.
- Overriding defaults – You can override all of the options now.
- “Jumpy” – I’ll admit to not spending much time trying to style the edit process to make it look smooth. My primary concern has been making it work and work fast. You could always add in script.aculo.us effects for that sort thing I suppose.
- Saving text – Any reason why you couldn’t use CSS to position the saving message some where else? Also templates for the edit form could help with this.
- Callback functions – I haven’t explored this idea yet, I’ve added it to my todo but I’m not ready to commit to including it yet.
- More Flickr like – I’ll admit to basing the edit form from Flickr, but this goes back to the “Jumpy” issue I think.
In addition I’m looking to make onblur act like the cancel button and adding support for the password field type.
So go check out the example page, which has been updated to make use of some of the new options in 0.3.0. If you have questions, comments, bugs, etc. please leave a comment or drop me a note.