I found that current js code make clicktoedit usability terrible - when user clicks on field to edit there is no natural way to "close" field to its display state. furthermore Dirty Forms module, which utilizes onBeforeUnload API to warn user of unsaved content went crazy on such unclosed fields. I tracked problem to line 

$(this).change(function() {
              Drupal.editablefields.onchange(this);
            });

If I use BLUR in stead of CHANGE form feels and performs much more naturally, user can close open fields even without editing its contents. To even more improve UX I plan to add save button to whole node template, so that user can lose focus familiar way.

Comments

henrijs.seso’s picture

henrijs.seso commented

here is how I got beautiful save buttons next to field...

            var curr_id = $(this).attr('id');
            $(this).not('[type=hidden]').after("<span id='tmpsave-"+curr_id+"' class='tmpsave'>Save</span>");
            $("#tmpsave-"+curr_id).click(function() {
              Drupal.editablefields.onchange(this);
            });

Will investigate more to see how to display one button for TO/FROM dates fieldset...

henrijs.seso’s picture

henrijs.seso commented
Title: save unchanged fields - 'change' event is bad for UX, 'blur' + button instead » save unchanged fields - 'change' event is bad for UX, 'click' + button instead

Updated code, among other improvements now generates one button per form so date fieldsets are saved correctly, also removed button after click and adds unique #id to button... only problem left is how to make button text translatable via drupal...

            var curr = $(this).attr('id');
            $(this).not('[type=hidden]').parents('form').not(":has('.tmpsave')").append("<span id='tmpsave-"+curr+"' class='tmpsave'>Save</span>");
            $("#tmpsave-"+curr).click(function() {
              $("#tmpsave-"+curr).hide();
              Drupal.editablefields.onchange(this);
            });
coderintherye’s picture

coderintherye commented

Would be nice if you would create a patch and provide that here.
Instructions on how to create a patch are here: http://drupal.org/patch/create

henrijs.seso’s picture

henrijs.seso commented

so, translatable buttons are easy Drupal.t('Public'); patch is possible, when Ill have a minute of time...

entrigan’s picture

entrigan commented

I agree editable fields should not save on change.

I think the use cases here will vary a lot, so maybe what we need is a configurable "Save/Cancel Method".

Possible options:
1. Save, Cancel Buttons (the method outlined in #1).
2. Editable on Focus, Save after loosing focus.
3. Enter to Save, ESC to cancel.
4. Global/Per View save/cancel button.

coderintherye’s picture

coderintherye commented

I tried this module out with a client. They liked when the default state was in edit mode for them, but wanted the fields to save once they lost focus. When I changed to the "click to edit" method, the client absolutely hated it.

Personally, I'd prefer the same, click to edit, click out of box to trigger save.

So +1 for method 2.

OliverColeman’s picture

OliverColeman commented

I've created a patch which includes a "Save" button over at #787598: WYSIWYG API. The main point of the patch is to add support for the WYSIWYG module, but this was most easily accomplished by using a Save button instead of the onblur event...

At the moment it only works for the Click to edit display type, and the Save button saves and closes editable field.

entrigan’s picture

entrigan commented

Nice, I will give that a test later. Do you think different "UI styles" (e.g. save button vs. blur) should be different formatters or global editablefield settings? My concern is packing in a bunch of formatters would just feel heavy. However maybe a compromise is to have a variable store which editablefield formatters are available.

andreiashu’s picture

andreiashu commented

Hi,

I think the patch(es) over at #359216: huge memory requirement for view with editable fields. should fix this problem. Basically it will change the form back to it's display state when you unfocus it.

Cheers,
Andrei

andreiashu’s picture

andreiashu commented
Version: 6.x-2.x-dev » 6.x-3.x-dev
Status: Active » Needs review

A 6.x-3.x-dev snapshot release shold be available on the project's page within the next 12 hours. Please test and see if it fixes this problem.

andreiashu’s picture

andreiashu commented

Re #7: Please correct me if I'm wrong but I think it makes more sense to have the save button only for clicktoedit fields that support multiple values. For single valued fields, the onBlur event should be fine, right?

henrijs.seso’s picture

henrijs.seso commented

andreiashu, thats correct, but for consistency it is good to have option to have save button for all fields.

andreiashu’s picture

andreiashu commented

@Lava: If I'm not mistaking, currently you can't have more than 1 active clicktoedit datepicker fields (think views).
If we take consistency into consideration then the default behaviour for clicktoedit formatters is to save on change or on blur (un-focus). Saving on change is valid for all the editablefields formatters. Adding a save button to all formatters wouldn't help much but it would add an additional unnecessary click to a lot for forms that wouldn't normally need one.

Please also take into consideration that editablefields is used al lot in combination with views too so performance/memory consumption is important. Read more about this here: #359216: huge memory requirement for view with editable fields..

andreiashu’s picture

andreiashu commented
Status: Needs review » Needs work
entrigan’s picture

entrigan commented

@#10, the behavior in 3.x is in my opinion much cleaner. Thanks!

@#13, Not sure if I follow you. You are saying that having a save button on every clicktoedit field is bad because in most cases it is unnecessary? I agree that save buttons should not be the default (unless it is required by the field type), however as I am sure you have gathered by my other posts, I love settings. Why not make the default UI configurable (globally, as I think per field settings would be a bit much)? I think there are a lot of cases (mission critical data perhaps) that would make people want to have users confirm their changes with a click of save.

andreiashu’s picture

andreiashu commented

@entrigan: I agreed that being able to change these default settings would be a very nice to have feature. I was actually thinking today of having a editablefields formatters page where you would be able to create additional formatters and set their settings. This is something that can be done in the future but for now I think it's best if we add that save button only for fields that need it: multiple valued clicktoedit fields.

Cheers,
Andrei

OliverColeman’s picture

OliverColeman commented

I agree with #15 that we could provide settings for what actions will save the field and perhaps what buttons if any are displayed (for click to edit fields at least I'd like to see several buttons: Save, Save and close, Cancel). Default global options would be good, but also per-field settings would be nice (I'm pretty sure I'd use them in my current project).

As for the settings UI, perhaps the editable fields settings for a field should be separated from the formatter drop-down and put into a separate column in its own drop-down (for the three current settings of Editable (Ajax), Editable (HTML) and Click to edit). Of course this means that this would also have to be implemented separately for the Views UI, which is a pain, but it would result in a much simpler and cleaner settings interface. Actually, no it wouldn't... If we had the per field settings mentioned in the first paragraph of this comment then we'd probably end up with an overly complex settings UI for the Display Fields tab in content type settings and Views field display settings... so the proposal in #16 makes a lot of sense: put all the editablefields settings in formatter "profiles": keeps settings UI simple and allows reusing the formatter profiles, and doesn't require implementing separately in Views (and possibly other modules). </outloud thinking>

I can see someone (eg me) thinking it would be very nice to be able to have a consistent interface for all editable fields (eg a save button is the only way to save a field). Of course this would only be sensible for click to edit fields (eg in Views) or a single node page; this wouldn't be very practical for Views if "editable (HTML|AJAX)" was used and many fields were displayed, as noted above. Which is why I think it would be great to make a fields behaviour configurable: so the site builder can decide what is best for their case.

At the moment for me it's pretty much imperative that single value text fields can have a save button so I can use the WYSIWYG module with editablefields (#787598: WYSIWYG API).

andreiashu’s picture

andreiashu commented

@Oliver: it seems that you are getting to the same idea as me: we need first to have very sane defaults, make the modules as simple as possible and then, if we have time we can extend on that.

This is very important: let's be realistic and try and implement the most needed things first and then, if we have more time we can expand. Please note that the development time for this is quite limited and I think it's really important to have the basic functionality stable (see imagefield, nodereference, multi-valued fields). We don't even have a "Add More" button for multi-valued fields which in my opinion is quite a major flaw.

I'm going to open a new ticket for the formatter's customizations page which is going to be a lower priority compared with this ticket and the WYSIWYG one.

Cheers,
Andrei

andreiashu’s picture

andreiashu commented
Title: save unchanged fields - 'change' event is bad for UX, 'click' + button instead » Provide a Save button for some fields

Is this is better title?

andreiashu’s picture

andreiashu commented

Reminder to self: we need Save/Cancel buttons for fielfield/imagefield fields (aka the file gets removed from the node only on save, same thing for adding a file to the node).

OliverColeman’s picture

OliverColeman commented

Perhaps we could have a Cancel button for any field that has a save button? Although for the Editable (HTML|Ajax) formatter it probably make more sense to call it something like "Reset".

hlopes’s picture

hlopes commented

Subscribing

TimelessDomain’s picture

TimelessDomain commented

subscribing duplicate issue #839406: html with submit button - preventing accidental submissions

pitxels’s picture

pitxels commented

The current UI is fine, but I think users would want to configure this options.

For example:

1. Currently onfocus edit, and click out for saving.
2. Edit and save buttons next to fields (with performace warnings)
3. General edit button and save button that will use ajax to make the fields editable and the save the info making the fields non editable again. (my favorite)

pitxels’s picture

pitxels commented

ok I have found the 1st and 2nd suggestions are already implement, though I don't understand the difference between edit ajax and edit html.

The 3rd suggestion is my favorite option, and would be great to have it implemented.

yesct’s picture

yesct commented

#1123640: Filefield and Image field half work with editablefields marked as duplicate of this issue

martidaniel’s picture

martidaniel commented

Hi mansspams,
Thanks for the code. But May I ask you in witch line are you pasting the code?
Thanks again

henrijs.seso’s picture

henrijs.seso commented

Back in those days I did not know how to make a patch :( and these days I don't remember. Now that I think about it, I was dumb to spread code like this.

As far as I can tell, these methods are already in module, at least in 2.0 -dev version it looks like code is there.

martidaniel’s picture

martidaniel commented

mansspams Oh my god, I did not realise! The posts are from ages ago. Sorry about that. Thanx for the info. I´ll have to look for other options because I cant add a save button with 6.x-2.0 version. I´m working with panels and I want to have editable fields but once I edit the field I cant save and close the edited field. Anyway. Thanks for your help anyway

mengi’s picture

mengi commented
Issue summary: View changes
Status: Needs work » Closed (won't fix)

Per https://drupal.org/node/2148735, 6.x is longer maintained so issue is closed. If you wish to be a maintainer of the 6.x branch please create a new issue.