How to deal with form validation when editing in-place?

Yes, I've already talked to Kevin about this at some point, but we had more pressing matters to fix first. This is definitely a major IA/UX thing we still have to deal with.

We should seriously consider leveraging the http://drupal.org/project/clientside_validation module for this.

Please see #1564920-37: Explore existing UX-enhancing solutions in Drupal to #1564920-40: Explore existing UX-enhancing solutions in Drupal for details.

This is a really good point. I will install clientside_validation on my local and explore design options.

@tkoleary - I'm available to help as needed on this. I really want this for D8.

@moshe: you really want client-side validation?

@moshe I'm available as well, and I don't even mind that we have a 'proper' validation in core ;-)

d.o fail.

I have some concerns about that approach. First, I'm not so sure about squashing revisions. Once the webserver saves a revision, it could be considered public and thus rebasing is not a good idea (borrowing git language here). We don't offer clones of our repo, so maybe it is OK. if we don't allow squashing, then the concerns are:

1. Can lead to many many revisions. This point may or may not matter much.
2. Each revision is small and not part of a coherent changeset. This makes it hard to build approval workflows on top of Edit in Place. The precise diff that
   one is approving is not 100% clear.
   

   One alternative is to use standard Ajax forms to build up a series of edits. Then the form gets Submitted when user clicks Publish. At that time, we perform validation (for the first time) and show errors as best we can. I think we could associate errors back to the parts of the entity that are invalid. i guess this has been explored?

   The other wrinkle is that we will soon have TempStore API but thats not needed for the technique I propose above.

#13: The revisions would be marked as being "in-place editing revisions" (terminology TBD). They'd be squashed to form a coherent changeset, which would then also make sense in the context of workflows.
Sounds okay or not?

A series of edits by building up state in an AJAX form doesn't work because AFAICT that prevents us from re-rendering the field as it will eventually look.

Lets see what others think of squashing. I'm on the fence. I guess Rules module would ignore such revisions when it does stuff like send email notifications. Also, we need to avoid cache clears for transient revisions.

Yeah, re-render based on not yet submitted values sounds messy. In order to get AJAX proposal to work, we'd need to accept a limitation where your "TRUE WYSIWYG" fields always show latest value but taxonomy and similar fields just have a 'Changed' highlight or something like that. They would not actually show the new value(s). We could possibly work around this for core field types but that is getting messy.

I have one (minor) other concern, what if 2 related fields need to be validated together, will that be possible?

This is minor, the only time we used such things is on intranet applications, not a really good fit for inline editing, but I'm just curious.

I think that if you do a node_save rules will kick in, and starts doing his things.

What if someone posted a revision in between all the ones you wish to squash? That would really complicate the squash, no?

@attiks: That would be near impossible to support, yes.

@moshe: we'd only squash specially tagged revisions by the same author, not simply "every revision since X".

So client side validation is out of the picture?

Do we really think that users understand, that although in front of them in the actual site they see the text changed. They still have to click "Save" for others to see it? We have this same issue with reordering items in a table, all to often people forget to actually click "Save". I imagine since this is in the actual front-end it would be even more so. Although, this issue is not necessarily related to this thread, I never really understood how we think this actually ends up working for our users.

I think the interaction proposed where tabbing out of the field triggers validation, sounds good to me (almost sounds like client side validation, heh). Although I am sure, just using a red line around it is not enough signaling to pass accessibility team review. Having the changes all squashed in the end sounds fine.

- If a validation error is hit, form will be returned w/ red outline and error message(s) below

If this is being performed without user initiation, then we need a live region to read the errors.

We likely need an abstracted method of providing visual / live region updates. A couple of other issues that highlight this are #1272990: Make tabledrag warning message show when row weights are enabled, and add WAI-ARIA live region and #1333292: Screen-reader users receive information if file upload was successful.

Tempstore has been committed. Seems like we should use it. See #1642062: Add TempStore for persistent, limited-term storage of non-cache data

Or below the field, if it's using the "direct" in-place editor.