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.
10 replies on “AJAX Edit In Place With Prototype, Version 0.3.0”
Can’t wait to try it out – will report back.
Thanks Joseph.
I haven’t had much time to look through it but I’ve come across one way you could optimize some of your code: you have an options object literal, which you loop through to assign each value to an internal array. Use Prototype’s Object.extend(default, options); This will map all passed in options over the default options leaving an updated default object. Also, change the EditInPlace = function() {} to just EditInPlace = {}. The first version is classable and multiple EditInPlace’s could be instantiated. Whereas, it looks like you just want a single object from which each item is “MadeEditable”. Although, it might make more sense to make EditInPlace a class object from which each instantiation would do the same as makeEditable and through which you could pass in your options, instead of what you seem to be doing which is storing each new editable items options in an array.
Anyways, just some initial thoughts. Thanks for continuing to work on this. 🙂
This is a great code!
Thanks alot!
I think it would be really cool if it is possible that text is saved in the users cookies, zo it is still edited when he comes back to the page, like it is now, the text is back to default then.
Somebody tryed to figure that out allready?
Dries,
I think the idea here is to have the update page one that actually updates a database – that way the content of the editable area will be updated when the user returns. Joseph’s just put together a quick example of how it works 🙂
hey,
I´m sorry, hehe, I just had this idea, but I will try to figure it out myself. 🙂
Joseph, thank you so much for this. It’s fantastic! I’m sitting down today and playing around with styling and some scriptaculous effects if I have the time. A simple improvment is adding an animation image as the saving_text string. I took the “arrows” indicator for Ajaxload and it really looks the part!
I tried to use the code to work on multiple id on the same page without success. Any ideas?
// Basic example.
for(var i=1;i
Just a quickie to say that I’ve been playing around with EditInPlace for a few days now, and have added some basic Moo.fx transitions to the saving process. Someone might want to use this as inspiration for enhancing the script further, but for now, I’m happy with some basic effects.
Animating EditInPlace.js with Moo.fx
i got this great script implemented pretty quickly on a new website i’m working on,but i need to customize it a bit to send the edits to a database. I’ve been fooling with edit.php, but to update the database I need to pass more information (like the primary key) to edit.php. I’ve tried to add session variables and fooled with EditInPlace.js some, but to no avail.
There has got to be an easy way to send some arguments, now stored in PHP variables from my calling page, to edit.php, right?
btw – I used Session Variables to pass data to the edit.php script so it could properly update my database.
If there is an easier way (i.e. passing variables directly through the javascript calls) let me know please.