Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi, we would like to propose a new (non-input) attribute: Markup (ressembles a distant memory of a Drupal custom field hence the name)
Prior to _guid becoming externally available we had a (readonly) .uuid field that duplicated the internal guid to make it externally available (for integrations with other systems, for instance an external DAM).
Now that we can grab the _guid itself it seems redundant to keep that duplication flow, but that now limits us to show the _guid only in a display template (like a summary display, search listings, exports, ..).
It was a nice feature to have the uuid anywhere we wanted (whatever tab, whatever placement and position; as well as all other displays).
An Agile inspired 'minimal implementation' could be this Markup field that just renders the fields own display template.
This has a few peculiarities though. Like a field is normally unaware of its context (so this version has to detect and load the context itself - like "I'm in object editor for 1234"), and it acts like a singleton (all 'placements' would react the same - depending on the context that is).
That makes most of the other field configuration options redundant too (repeatable, required, regex, ...), but never touched because there is no form element to be saved.
The normal way of rendering placements through the jquery uis (what value in what context) would have required new ui elements. I didn't pick that more elaborate route for this POC.
This one use-case we had (just print
<h3>^._guid</h3>) can (as-is) easily be used for other use-cases as:more elaborate 'documentation', offering direct links to the DAM using the _guid, rendering an external image thumb resource using the _guid, just 'plain'/formatted text reminding the authoring workflow, special attention cues in authoring maybe combining existing field values (Seems entities._count>4 so only two different menu selections allowed by kitchen demand),..
using (non-input) [your-fav-js-framework-here]-components, or even webcomponents like
<script type="module" src="https://unpkg.com/wired-elements/lib/wired-calendar.js?module"></script> "Reminder: no more edits after" <wired-calendar selected="Jul 22, 2026"></wired-calendar>(with the proper unpkg, jsdelivr, ... SCP in index.php), using fixed text or again other fields values, ^ca_objects.some_date, (3D) depicting textual chemical formulas ^ca_objects.chemical_formula, offering scientific calculators or drawings to help input of following fields, sheet music incipit render/player,...good old
<iframes>rendering other useful documentation sites :)future extensions could perhaps persist the outcomes of these Markups (as a snapshot, or for instance all the steps made in the calculator to arrive at that value in the latter field),... however that would probably be better of with other custom field types
An unpolished crude example could be (legacy uuid vs bulked _guid)

from https://github.com/rough-stuff/wired-elements