Inline Editing and the WYSIWYG module

Personally, I don't think inline editing belongs in WYSIWYG, because WYSIWYG is essentially nothing more than a tool to configure and attach editors to input formats. If we tie in the inline functionality, it would probably be a pain to support anything other than a fields with a format.

If we were to abstract that functionality in a separate module, which would do nothing more than grab the form for said entity, only show the field being edited, and handle submission, then it should automatically support any input field you throw at it, including fields with a format (and an editor attached by WYSIWYG).

This would make it a lot easier to support things like a date field with a date picker attached.

Sexy demos and Dries mention or not, I don't think that inline editing is necessarily a good fit [edit] as the primary way [/edit] Drupal manages content. I could see it being the main editor on a small brochure site and supplementing on a site that leverages Drupal's serious CMS muscles, but Drupal is built from content out. Inline editors act from display in. How do you manage metadata, taxonomy categories, or fields that don't display in your current context but are part of the content you're editing right now (slug, teaser, full node)? How applicable is inline editing to the spectrum of Drupal sites that use WYSIWYG, news journals to commerce sites to tumblr clones? Without going off on a tangent I think there's a discussion that needs to be had on how inline editing can work with Drupal, and it's something that should probably happen before deciding to add inline editing's complexity and development load onto the contributors and codebase of WYSIWYG.

Seujte mentioned in another thread that every new editor doesn't need seven years of vetting and proprietary code before it gets folded into a project with longevity and a widely used api like WYSIWYG, but this is more than a new editor. It's a different way of editing content entirely, and although that's exciting it might not be the best fitting tool for the job. Some proof of concept in an Aloha module -- or even a non-wysiwyg inline editing api -- seems like a good idea before deciding to refactor a workhorse to fit into an evening gown.

Seutje and RobW bring up good points there. Bringing inline editing itself to Drupal is out of Wysiwyg's scope, at least considering the way things currently work.
If a module would do what Seutje mentions in his second paragraph, Wysiwyg should already be able to detect that the new field added to the page supports formats, find which editors are associated with them and load the corresponding profiles and clientside scripts as well as launch the editor. (We probably need to get a patch or two from the queue polished and committed for it to actually work nicely in practice, but that's not much work compared to bringing the mechanics of inline editing into this module.)

If there's need to support additional editors in Wysiwyg to make the experience smoother and nothing is happening in Wysiwyg itself (stability issues, incomplete patches/testing, other bugs, missing features, maintainer absence, whatever), it is possible to use various hooks to extend/override parts of Wysiwyg or implement editors from other modules and continue development in parallel for now. I'm not saying that is the way things have to be done. I just don't want other developers to think we absolutely must be actively working on this in Wysiwyg itself for features like inline editing to move forward. I can only speak for myself but I have a feeling Sun would agree - considering he's got a lot more modules, and Core, to focus on - that we've got more than enough support request, bugs and other issues to keep us busy already, so this particular feature is low on the list. If a well thought through, constructed, documented and reviewed patch be put forth and inline editing lives or dies with it, I'd do my best to get it committed ASAP.

Simple proof of concept: https://github.com/seutje/easyedits
ajax handler doesn't get added though, and as RobW mentions: only fields that are displayed can be edited as it is setup as a display formatter
it's probably horribly inefficient and stuff, but it should give you an idea how small it can be and how this approach automatically supports a lotta things like wysiwyg module

Cross-reference: Inline editing will most likely require #356480: Lazy-load editors.

#4: it *seems* (but I can definitely be wrong) you're reinventing http://drupal.org/project/editablefields there, but with better behavior: instead of always showing the editable fields, you only show the forms when it has been clicked :)

my Google-fu is failing hard lately :x

#8: no, that module doesn't support that, but seutje was building that: see #4 :)

AFAICT: yes :)

hmz, hadn't thought of using a little link for it, neat idea. I was hoping to get away with 0 module CSS though...

This is already being worked on in the following module:
http://drupal.org/project/edit

No use in reinventing the wheel.

Also, you might want to check out...
http://drupal.org/project/editablefields