Support for contextual editing of fields on the page

Contextual editing of individual schema fields on the page is often desirable, especially for string fields, and could begin with string field support.

The syntax might look like:

apos.contextField(data.piece, 'title', 'h1')

This would result in minimal markup, to avoid breaking wysiwyg experiences the way a full schema form would. The h1 tag would be contenteditable, which is hopefully not a choice we’ll regret because no editing UI other than typing text would be allowed. min, max and required would need custom implementation. Markup would need to be escaped and de-escaped, and changes would need to lead to debounced ajax save operations, possibly including changes of the URL (without refresh).

The type of the doc and the type of the field would be looked up in the schema to determine what to do, and an informative error thrown if the situation cannot be handled. For instance: at the beginning at least, this probably won’t work for fields of widgets, nested properties, non-string fields, etc.

Something intelligent has to be done if the user presses ENTER in a string field that doesn’t have textarea: true.

It would be nice if the helper name was just apos.field, but in 2.x that is too likely to conflict with a module name at project level. Perhaps in 3.x.

cc @abea

[boutell]

An objection to element is that you can’t put classes on it. We could add attributes to address that.

On Mon, Apr 29, 2019 at 1:14 PM Tom Boutell [e-mail] wrote:

We could do span, but that’s not a clean mapping to what logged out users would probably see, right? Or would we force the span on them too? Why the extra markup when it’s legal for an h1 to be contenteditable?

Probably do need an options object though, what I wrote here is not extensible no. { element: 'h1' }

Speaking of which, what does contextField do if the user can’t edit? I should think it just outputs the content in the appropriate wrapper tag, without contenteditable. So you don’t have to write a big “if” clause if you don’t need to.

On Mon, Apr 29, 2019 at 10:43 AM Alex Bea [e-mail] wrote:

I’m not sure about the h1 part of the arguments there. I would expect that to be the field type, not the markup wrapper. While we’re not going to have other field types immediately, this prepares us to have this be number or whatever later on. Maybe that doesn’t matter if we’re looking up the schema based on the context and name, though…

I would think we default to a span, though options could include a different element (limited to text elements). If sticking with span the developer would wrap it in the template as one would now.

On naming, if this needs to be limited to fields already in the schema, schemaField may help communicate that. But it may be possible in 2.x to have this be added only to templates as areas are now, in which case contextField makes sense.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/apostrophecms/apostrophe/issues/1893#issuecomment-487607752, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAH27PELC62O5KEJQ3QRATPS4CPVANCNFSM4HJDXZZA .

–

Thomas Boutell, Chief Software Architect P’unk Avenue | [phone] | punkave.com

–

Thomas Boutell, Chief Software Architect P’unk Avenue | [phone] | punkave.com

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.