[Proposal] Updating field handling functionality in TiddlyWiki

Developers
, ,
#64

I mean… do we? I know you were considering a implementing a config-tiddler cascade that would search for relevant fields on tiddlers whose titles fit any of several proposed patterns. I think this adds complexity (and perhaps some rendering time, on a tiddler with a lot of fields), but if it works, then you’re right: no one is technically required to use a particular naming scheme. At the same time, shared tweaks and solutions are a cornerstone of the TW community, and it’s much easier to share them if we can all agree on some general naming conventions. I think whichever convention you promote as the preferred "default’ (or the one that’s used by the core, should this make it to the core) is likely to become the de facto standard. So I think it’s worth finding one that “works” for the most users, and I commend you for spearheading that discussion.

Just to clarify my stance a little further…

I support nearly every aspect of your proposal as I understand it except the use of ▭ (or any other non-standard character) as the default or preferred prefix for field-config tiddlers. Why?

  • If I want to edit a specific tiddler (especially a system/config tiddler), my first instinct is always to search for it. I understand that a hypothetical ▭ source tiddler would also come up if I searched for “source” (since it’s not a system tiddler). But this doesn’t really help me if I want to search (or perhaps more likely, filter for) all the field-config tiddlers, because I can’t type ▭ unless I happen to know its unicode value. I can copy-paste it, but only if I’m already looking at it, and copy-paste gets even more tedious on mobile.
  • This means [prefix[▭]] — a very simple filter and, IMO, a reasonable category to want to filter for — is significantly more difficult to type than e.g. [prefix[$:/temp]]. This feels inconsistent with the principles of good TW design as seen in the core — not to mention close analogs like tags, where you modify the appearance of a tag pill by adding fields to the tag tiddler itself.

For that reason, I’d support @Springer’s “transparent” approach over one that requires an obscure prefix. I think it’s more internally consistent and also more intuitive from a user perspective. My only real concern is that it makes it difficult (or risky) to grab @Springer’s source field because I like her field configuration when I already have a source tiddler with its own non-field-config content.

You’re right, of course. There are a lot of plugins out there that aren’t for me (because they require a specific layout, or the code is hard to work with, or I don’t care for the design choices, or just because they haven’t been updated since 2020, etc.) but they’re for someone, and I think that’s great!

There are also a smaller number of plugins I liked conceptually enough to hack into a form that did work well for me, and some of these I’ve even repacked for my own use. This is a perfectly viable solution (though not, I suspect, a popular approach — it’s tedious!) and I’m glad that TW gives me the tools to do so, and grateful to the developers whose work I’ve frankensteined. But it does make it harder to get updates, and harder still to share solutions with other users. (“Well, you can do this with Shiraz, but I’ve actually added four parameters here and rewritten five of the constituent macros…”) So since you were thoughtful enough to solicit input prior to building the solution, I thought I’d try to campaign for a format that might not require too much tweaking. :slight_smile:

#65

:thinking: As far as I understand, I (as an ordinary user) would never have a reason to want to create a shadow tiddler, except if I’m building a plugin-like solution (one where I’d need to establish a default suggestion while expecting some other end-user might prefer something else, even while needing my basic default to remain as a fallback if their variation is lost, or creates a mess and needs to be nixed). I don’t see where it would occur to anyone to create a shadow tiddler for their own non-developer purposes (though of course having backups of prior versions of this and that is always a good thing).

By contrast, I certainly want to be able to configure how fields work in my own wikis, and this interest emerges organically in working with TW as an end-user.

Since I can currently do so with ordinary TW5 skills (meaning, no javascript), I don’t think of a basic plugin in this area as enabling a new thing.

(Perhaps this is where your concerns, and your skills, are beyond mine! I’ve been thinking of offering a simple plugin, and it’s not going to involve any new javascript, and it would not bake in any expectations about fieldname prefixes (except perhaps in the fields-about-fields — see below). The goal would just be to make access to the deeper power of fields more convenient, and to to include some signpost-like documentation and useful templates.)

I think in another neighborhood of our conversation you were recommendation a prefix for the “fields about fields” — such as field-description or field_is_longtext (or whatever). That strikes me as a great convention with no downside, and the remaining challenge is just whether we can avoid relying on the English word “field” in that prefix — while still making the convention keyboard-accessible, and intuitive enough (hence my thought about leveraging §).

But if you mean that you imagine all (non-core) fields should have a prefix… :upside_down_face: … That would be a non-starter for me. In my ordinary work, I’m absolutely committed to fieldnames like “score” and “word-limit” and “DoB” and “user_id” — partly because I’m importing and exporting JSON data with other database systems with their own fieldname conventions, and partly because Shiraz tables work most conveniently with compact fieldnames. …

On the other hand, I do think distributed TiddlyWiki solutions should be careful to avoid barging into plausibly in-use fieldnames within the “customer” wikis that might adopt those plugins…, so purpose-specific (bibtex-) or developer-specific (PSaT?) prefixes are great in that respect. Maybe that’s all you meant?

[EDIT: I realize after a few moments… perhaps you meant not that the fieldnames themselves would have prefixes, but just that the tiddler (where info about the field lives) would have a prefix, so that the fieldname is a substring of that tiddler’s name. IMO, this creates some confusion, because if there can be a regular-old tiddler called bibtex-LCCN, it seems odd to expect that tiddler to be “divorced” from the meaning of that string as a fieldname… But I do see room for flexibility here!]

Great to be having these important conversations about where the opportunities and risks are!

#66

once again thanks @Springer and @etardiff for your feedback

I don’t have enough time for full answers just now but will reply more later

to be clear I propose a mechanism where by default field tiddlers are named exactly the same as the fieldname.

  • however a global prefix can be set such as $:/fields/ which can be used to hide away the field definitions
  • there will be a mechanism to override this prefix on a per tiddler basis allowing custom prefixes to be used for specific tiddlers

if neither of these are resolved, a tiddler does not exist, it uses the default and if no field definition tiddler is found it behaves as is.

  • if a tiddler exists by the name of the fieldname it will not assume it is a field definition unless it contains something else like at least one field with the prefix field-

I think the above addresses all your concerns while maintaining the hack ability I am looking for.

  • using unicode prefixes which is what I like is a red herring because it’s not part of the solution but a designer could choose it and it will work along side what other designers choose to use.

to find field tiddlers I intended to introduce filter operators like all[fields]

I will address your replies directly soon, next day or so.

thanks again.

1 Like
#67

I cant get to involved here for now as I need to prepare to move home, from a house sit I have being
doing :nerd_face:

We can add to this “hackability” as another cornerstone.

My idea is that we have four posible “field tiddler” namespaces;

  • local tiddler field provides a prefix name (optional eg comes in a plugins tiddlers, could be anything)
  • a system-field-prefix by default $:/fields? (can be changed?)
  • a standard-field-prefix by default (as a we agree eg § ) can be changed?
  • No prefix at all just fieldname (Perhaps the default)

The above will be itterated for each field and find the first existing field tiddler from the top down and use that.

  • later we may also use the same “cascade” to determin how to display a field, or edit from the view template.
  • This resulting field tiddler namespace will be used in the editor to link to the field tiddler, and other features;
    • Description/tooltip
    • values filter
    • field-type…

New field tiddlers

However initialy at least most fieldnames will not have a field tiddler.

When creating or editing a tiddler, any field without a found “field tiddler” can be clicked on to create a field tiddler. I would suggest the default is just “fieldname”, however I also suggest the “field editor” have an option to change the “new field tiddler default” including; “no prefix” default, “standard prefix” and “system prefix” to allow easy creation of field tiddlers using these other namespaces.

  • As configured above
1 Like
#68

I am working on my own implementation of this following much of the advice from the community. Initialy as a Proof of concept.

Background

It is an example of a project that is very meta as when you design field handling you need to create fields, which you would love to do with the solution you are building. One of the key issues is do we creat field tiddlers by the exact name and not hidden behind $:/ I am doing this for now but hope to allow a local override one day. However having defined my first field tiddler, I now need to define a field-type tiddler. For example the description field may be text which implies an 80 character text field.

Current Question

Here the same question arrises will field-type tiddlers also live in the standard tiddler titles. In the above example the description field now needs a field-type tiddler of “text” which seems way to generic. Should I hide field-type definitions behinfs the $:/ with a prefix of $:/field-types/ giving $:/field-types/text

#69

I think @Springer’s work has convinced me that this is the best idea. It’s not perfect, as it makes it harder for those who want to do so to hide the TW skeleton inside their wiki, but I think it’s a good start, and as I mention below for field-type, this sort of arbitrary configurability makes it much harder to share tools across users and wikis.

Why the 80 characters? I don’t follow.

Perhaps plain-text or short-text? Something to distinguish it from long-text that you might use with a textarea element?

I’m tempted to say, add a $:/config/field-type-prefix that might be blank, or might hold $:/field-types/ or something else. But I’m pretty sure that’s a bad idea. It would make it much more difficult to share groups of field types across wikis, if they have different values for these fields.

So, instead, I think this needs to claim a public location, and to my mind, the best place would be its own namespace inside $:/config, perhaps $:/config/FieldTypes.

#70

I totally disagree on this, What I propose is very simple, although apparently hard to understand, because every one keeps telling me its too complex. It is not. What it is, is forward thinking (if I say so myself)

  • Make fieldname tiddlers out of the box.
  • Allow a field on any tiddler to tweak this by choosing a prefix
    • Ensure when looking for the fieldname tiddler, if a prefix is available (on the current tiddler) use that first, otherwise revert to the fieldname tiddler.

Why?

Then I can write a plugin that makes tiddlers whose fieldnames exist within a custom namespace, thus allowing a fieldname to have a different definition to that found in the fieldname tiddler. Although it may still use a common field-type.

  • In fact it need only define fieldname tiddlers (with its prefix) that it needs to be different, otherwise it will default to “field tiddler”.
  • it in no way interferes with the default approach to fieldname tiddlers, and no one would be aware it exists unless they read the documentation, or code. Ir install a solution that uses it.
  • Rather than store the prefix itself I thought we could use a tiddler-type (singular) , or role (singular) so it is less technical to use. I prefer tiddler-types or roles (plural) but we need one but could use field-prefix to be more direct.
    • Elsewhere I am playing with the concept of tiddler “roles” surfacing a card “view” on the tiddlers for each role.

Note: field-types allow the sharing of code to handle different types of view and edit formats there is a much smaller set of these than possible fields. Such types can be shared freely as they can sit in your wiki unused. But if and when you want to use a field-type you can set it in a field tiddler.

  • This is in part why we need to jointly develop the field solution so we are all on the same page making both field definitions and field-types sharable in the community, resulting in a accelerating collaboration.

I think you answered that yourself with the next quote;

Yes, agreed but I suggest long-text and/or long-textarea to be clear.

  • The field tiddler could use a field-size field that the field-type uses so we would only need a field-type or text or textarea but the text can be given a size in the field definition, using a default if not available.

As above so far I am only proposing a tiddler specific override of this suffix option and although I would like to also have “a global override as well”, because I do think some designers will be unhappy with fieldname tiddlers coming up in search (thus may want such tiddlers behind $:/fields/ and field-types behind $:/field-types/), I am happy to “reduce my ask” for now to see this moving forward.

  • At least field types may be better suited to the $:/field-types/ prefix, because unlike “field tiddlers” they are less likely to be useful to the users of a wiki.

I don’t want to argue expertise on this, and I remain open to valid criticisms, however I have progressed into building such a field handling a few times and learned a lot of lessons on the way. So I hope this has some influence on peoples consideration of my position here.

#71

I just want to add that if we use the field- prefix for field handling related fields we can also use this to find all relavant fields. Similarly the prefix for field-type- handling fields.

  • This also makes it possible to have a one off field definition that also contains its field-type- definition
  • however the default should be an independant field-type tiddler as these are sharable without the need to link to a field definition.

Should I write a requirements document to pull all these ideas together?

#72

I certainly did miss the “on any tiddler” in previous discussion. It was probably there, and I missed it in my quick readings of these. But that is very different than what I assumed to be a global configuration.

Putting it on every tiddler – while it does make this slightly more difficult to use – removes my main objection.

I definitely prefer roles (plural) here. It’s only slightly harder to implement, and adds a lot of flexibility.

But I also prefer a layered approach. tiddler-roles would in my understanding depend on field types, but field types can stand alone. If we’re going to develop these as proofs of concept, I would like to develop field types on their own, and separately implement tiddler roles atop them. Because field types have independent use and are worth considering with or without tiddler roles. I don’t think the reverse is really true. (Or can you suggest otherwise?) To me a tiddler role would encompass a description, perhaps View/EditTemplates,. and a collection of field-name/field-type pairs.

Well, no. I think about the distinction between a single-line entry field and longer form input. But none of that specifies 80 characters.

While I still think I prefer the unadorned field name, I could certainly be convinced of this. Inside a field tiddler, I would expect the field- prefix on the field names, mostly to ensure that we’re not interfering with other possible uses of this tiddler. (So field-description, field-type, field-is-list, etc.)

I think that would be a good idea. But a POC implementation would serve much the same role. So either or both would be good. I was thinking of writing a POC myself, but only for field types and not tiddler roles. Mine would be similar to what @Springer has already demonstrated, but with minor differences, and without external dependencies such as Shiraz. I might follow that with a tiddler type implementation, but that will require more investigation. And I’m really not sure when I’ll have time for either.

1 Like
#73

good we are on the same page.

yes I am committed to roles and optional namespace prefixes but out of the box active fields, field tiddlers and field types.

using field- and field-type- prefixes helps separate the definitions from what we are defining and part of an approach to roles. however roles should be as independent as possible from field definitions but at the same time can use them.

  • no unnecessary dependencies
  • simplicity but adaptability which includes hackability
  • maximising shareable components

tiddlywiki is good for this

#74

:+1:

I’ll have to look again at some of the roles discussions, because my first thought it that a role is principally a collection of field types, with possible templates, and maybe a minor amount of metadata.

#75

we did not discuss roles too much but a few of us have a similar approach. My view is the same as above but I am exploring using what I call cards.

one or more cards can appear on the same tiddler.

we can have one view template tiddler below the body that iterates one or more roles on each tiddler and generates one or more cards. I already have this for shadows, missing, system, tag tiddlers, field tiddlers to assist in implementing field definitions but it could be extended to respond to roles in a roles list field.

  • by stepping outside the view template we can build our own logic including a display filter and the delist mechanism
  • you can always still use the card(s) through the standard view template cascade
  • cards delivered as a result of roles will be ordered in the order they are found in the roles field and can be reordered on each tiddler.
#76

If we are to allow a global prefix for tiddlers, rather than field tiddler named “fieldname” perhaps a config tiddler with suggested values could suggest prefixes;

  1. none ie fieldname - default
  2. $:/fieldname
  3. $:/fields/fieldname

The second option is very similar to the first only behind the $:/ system prefix

The same question can be asked for the field-type tiddlers

  1. none ie fieldtype - default
  2. $:/fieldtype
  3. $:/field-types/fieldtype

I favor the last because there would be little reason for users to find the field-type tiddlers.

In all of the above

  • if a field-prefix is given on a tiddler then that will be used instead
  • For fields the field definition will be the first found in reverse order
  1. $:/fields/fieldname
  2. $:/fieldname
  3. none ie fieldname - default

@Springer I see you have a sophisticated example on https://quick-demo.tiddlyhost.com/ could you please point me to the key modifications/tiddlers to implement fields so I can incorporate the IP in my POC?

  • I can find them but your help appreciated

[Late Change]
Perhaps the field prefixes could be driven by the order on a tag?

#77

FWIW, I’ve started implementing a field handling system in my own wikis based on some of the ideas discussed here (though less complex that you’ve been envisioning, I think, @TW_Tones). I’ve adopted the following conventions, which I present mostly as food for thought:

  1. Naming scheme for field tiddlers: $:/field/fieldname, e.g. $:/field/class

    • My largest wiki has over 700 fields, and most of them are not and will never be public-facing tiddlers. Some of them are purely functional (e.g. system fields like filter or is-dropdown); others might correspond to a “content” tiddler, but they use kebab-case, which I wouldn’t want for a tiddler title. In short, I just don’t want to create a lot of “standard” tiddlers just for field config purposes and then have them cluttering up my filters and search results.

    • If all my field tiddlers have a standardized name scheme, they’re easy to spot at a glance. It was also easy to include a template for rendering $:/field/... tiddlers in the ViewTemplateBody cascade—and I can display the same template on “virtual tiddlers” with the same prefix, too.

      • So far, this ViewTemplate includes a form for configuring the field tiddler (which will create it, if it doesn’t already exist) and a paginated dynamic table (Shiraz-style) listing all tiddlers with this field (has:field rather than has) and their respective values for the field.
      • I could theoretically do the same thing in a ViewTemplate segment on a “standard” tiddler, but if a tiddler with a given field’s name already exists, it’s typically because I’m using it to display actual content, and I don’t want to see all this meta info every time I open the tiddler.
      • I’ve gone ahead and converted all the field names in the Edit Mode field editor to link to their respective $:/field/... tiddlers, so it’s always easy to get to the field tiddler when I need it — which is typically when I’m already in edit mode and need a different field type for a given field.

    • I did consider using the prefix $:/fields/ (as you suggested above) just to parallel $:/tags/... … but honestly, I think plural /tags/ was a mistake! :stuck_out_tongue:

  2. Naming scheme for field template tiddlers: $:/field-type/..., e.g. $:/field-type/select, $:/field-type/color

    • I took this prefix (nearly) directly from the prior discussion here — though again, the singular form makes more sense to me.

    • I think you’ve been using “field-type” tiddlers to mean the templates that are used to render a field, like $:/core/ui/EditTemplate/fieldEditor/default in the current Field Editor cascade… if not, that’s how I’m using them. So my (modified) cascade looks like this:

      image
      image1042×433 21.9 KB

    • Sample $:/field-type/... tiddlers:

$:/field-type/default (plus global variables stored elsewhere) 
\function field-config() $:/field/ [<currentField>] +[join[]]
\function field.config(field) [<field-config>get<field>]
\function field-placeholder() [field.config[placeholder]] ~[{$:/language/EditTemplate/Fields/Add/Value/Placeholder}]

<$edit-text
	field=<<currentField>>
	tag="input"
	default=""
	class="tc-edit-texteditor tc-edit-fieldeditor"
	placeholder=<<field-placeholder>>
	tabindex={{$:/config/EditTabIndex}}
	cancelPopups="yes"
/>
$:/field-type/number 
\function min() [field.config[min]]
\function max() [field.config[max]]

<$edit-text field=<<currentField>>
	tag="input"
	type="number"
	class="tc-edit-texteditor tc-edit-fieldeditor"
	placeholder=<<field-placeholder>>
	min=<<min>>
	max=<<max>>
	tabindex={{$:/config/EditTabIndex}}
	cancelPopups="yes"
/>
$:/field-type/color 
\procedure set-color() <$action-setfield $field=<<currentField>> $value=<<colour-picker-value>> />

<style>
.field-editor-plus-button input[type="color"] {
	height: 2em;
	width: 15em;
	margin: 0;
	padding: 0;
	border: 0;
	outline: 0;
	border-radius: 5px;
	vertical-align: middle;
}
</style>
<div class="field-editor-plus-button">
{{||$:/field-type/default}}
<div>
	<$edit-text
		field=<<currentField>>
		type=color
		default={{{ [<currentTiddler>get<currentField>] }}}
		class="tc-edit-texteditor tc-edit-fieldeditor"
		cancelPopups="yes"
	/>
</div>
</div>
<details class="no-pad">
	<summary class="pad-tiny-l tc-small-gap-bottom b">Color picker</summary>
	<$macrocall $name=colour-picker actions="<<set-color>>" />
</details>
  1. Field tiddler templates: Any tiddler prefixed with $:/field/... will display in the story river with my field-config template, whether it already exists or not. If it doesn’t exist, editing the Field Configuration in any way will automatically create it — so this is very easy to do on the fly.
config tiddler for the "dropdown" field

image
image1220×528 53.6 KB

And here’s a meta one — the field tiddler for the “field-type” field.

config tiddler for the "field-type" field

image
image1242×595 37.7 KB

Here you can see…

  • I’ve searched for a specific set of tiddler(s) whose field values I want to see.
  • The field input is rendered with the chosen template (as specified in the field-type field — here I’m using “select”, so I get a select widget) which is also used in the standard Field Editor.
  • My configuration sidebar conditionally displays extra fields depending on the chosen field-type. For instance, “select”-type fields get some filter fields whose content is used to populate the $select (actually a $select/$edit-text combo) dropdown for that field.

Finally, here’s what a tiddler looks like in edit mode…

Field editor view

image
image1234×746 44 KB

You can see…

  • “description” is using a textarea-type template (as configured on $:/field/description)
  • I’m hovering over “dropdown”, which links to $:/field/dropdown and uses $:/field/dropdown!!description as its tooltip. If it were a “system” field, it would display the system field description (in the $:/language/Docs/Fields/... namespace) as a fallback if I hadn’t added a custom description.
    • It looks like you’re leaning towards prefixing all the field-oriented field names with field-, so I suppose this would be field-description instead. But I generally try not to add a new field if an extant one will do, and the core already uses description for brief descriptions, so I decided to recycle it.

I’m sure not all of this aligns with others’ preferred directions, but it’s been working very smoothly for me thus far, though I’ve still got ~400 fields to check (:sweat_smile:) and may add a few more field-types along the way.

Thank you for the inspiration!

3 Likes
#78

Thanks so much for your effort @etardiff your implementation is both similar and different in interesting ways. It certianly helps me feel confident I am on track. I have done something similar to you a long time ago, but this time I am hoping to open source/package the solution based on the community feedback.

One difference is the desire to allow multiple roles on the same tiddler. In part to accomodate fieldname tiddlers to map to the tagname tiddlers. However with your example and my own hunch I think I will hide the field-types behind the $:/field-type(s)/ prefix.

You kindly shared images of the various field and field-type configurations however have you an example of the result on a tiddler? Once a field handling is implemented there are different ways to see the result;

  • A way to view edit the fields in the view template
    • Through a custom template
    • through some kind of form or field list
  • Extending the Tiddler editor to use the definitions

Which approach(s) are you using?

#79

Ditto. I see how it came about, but… it’s just wrong.

#80

Feedback accepted

@etardiff I am trying to see how you inserted your system into the editor?

#81

This one:

I included a screenshot, but it was at the very end of my last post, so I’m not surprised you missed it.

I’ve been doing both of these through other methods for a long time:

  • A large majority of my tiddlers use custom ViewTemplates, and most of the complex ones include either an inline edit mode that can be toggled on without leaving view mode, or a custom EditTemplate section(s). To be honest, I don’t see my new “field handling” implementation being of much benefit here. My inline editors are generally customized to match the “read mode” display as closely as possible, with fields organized in the particular order that makes sense to me, placeholder text tailored to the specific tiddler type, and other “form” widgets like listField checkboxes, etc. None of this translates well to the global field editor, so I don’t see any need to build it into my field-type tiddlers.

  • I also have a button that toggles the “standard” field editor on at the bottom of a view mode tiddler. (I cobbled mine together a long time ago, but Mohammad has a similar feature in his Utility plugin — it’s the second button from the left in the page toolbar.) I use this sometimes if I want to do a quick ctrl-f on all my field content, or if I want to add an ad-hoc field… and since it’s just a copy of the same Field Editor segment I use in edit mode, this will benefit from my new field enhancements.

1 Like
#82

Ah, right, the one part I forgot to show you. :sweat_smile:

I use a cloned and modified version of $:/core/ui/EditTemplate/fields in my wikis (both in edit mode and in view mode, when toggled on). I’ll put the whole thing under a fold if you’d like the full context…

Modified Field Editor - full text 
\import $:/core/ui/EditTemplate/fields

\function system.fields()
[all[shadows]removeprefix[$:/language/Docs/Fields/]]
:filter[lookup[$:/config/EditTemplateFields/Visibility/]!match[hide]]
+[join[ ]]
\end

\function custom.fields() [fields[]] -[enlist<system.fields>]

\function field.config() [[$:/field/]addsuffix<currentField>]

\function tooltip()
[<field.config>get[description]]
~[[$:/language/Docs/Fields/]addsuffix<currentField>get[text]]
\end

\procedure field-label()
<a class="nav general" to=<<field.config>> title=<<tooltip>>><<currentField>></a>
\end

\procedure field-list(filter:"[all[current]fields[]] +[sort[title]]", class)
\define delete() <$action-deletefield $field=<<currentField>> />
<$list filter=<<filter>> variable="currentField" storyview="pop">
<$list filter=<<config-filter>> variable="temp">
<tr class=`tc-edit-field $(class)$`>
	<td class="tc-edit-field-name">
		<% if [<class>match[system]] %>
			''<<field-label>>'':
		<% else %>
			<<field-label>>:
		<% endif %>
	</td>
	<td class="tc-edit-field-value">
		<$keyboard key="((delete-field))" actions=<<delete-field>>>
			<$transclude tiddler={{{ [<currentField>]
				:cascade[all[shadows+tiddlers]tag[$:/tags/FieldEditorFilter]!is[draft]get[text]]
				+[!is[blank]else{$:/core/ui/EditTemplate/fieldEditor/default}] }}} />
		</$keyboard>
	</td>
	<td class="tc-edit-field-remove">
		<$button
			actions=<<delete>>
			class="tc-btn-invisible"
			tooltip={{$:/language/EditTemplate/Field/Remove/Hint}}
		>
			{{$:/core/images/delete-button}}
		</$button>
	</td>
</tr>
</$list>
</$list>
\end

\procedure new-field()
\whitespace trim
<$let name={{{ [<newFieldNameTiddler>get[text]] }}}>
<$button
	actions=<<new-field-actions>>
	class="tc-btn-invisible tc-tiddlylink"
	tooltip={{{ [.is<name>then[Add field]] }}}
>
{{$:/images/fa5/solid/plus-square}}
</$button>
</$let>
\end
\whitespace trim

<$let
	newFieldNameTiddler=<<qualify "$:/temp/newFieldNameTiddler">>
	newFieldValueTiddlerPrefix=<<qualify "$:/temp/newFieldValueTiddlerPrefix">>
	system.fields=<<system.fields>>
>

<div class="tc-edit-fields">
<table class=`tc-edit-fields ${ [all[current]fields[]] :filter[lookup[$:/config/EditTemplateFields/Visibility/]!match[hide]] +[count[]match[0]then[tc-edit-fields-small]] }$`>
<tbody>
	<<field-list "[<currentTiddler>fields:include<system.fields>sort[title]]" system>>
	<<field-list "[<currentTiddler>custom.fields[]sort[title]]">>
<$fieldmangler>
<tr class="tc-edit-field">
<$let
	refreshTitle=<<qualify "$:/temp/fieldname/refresh">>
	storeTitle=<<newFieldNameTiddler>>
	searchListState=<<newFieldNameSelectionTiddler>>
	popupState=<<qualify "$:/state/popup/field-dropdown">>
>
	<td class="tc-edit-field-name">
		<<new-field-selector>>
	</td>
<$let
	currentTiddlerCSSescaped={{{ [<currentTiddler>escapecss[]] }}}
	currentTiddler={{{ [subfilter<get-field-value-tiddler-filter>] }}}
	currentField="text"
	currentFieldName={{{ [<newFieldNameTiddler>get[text]] }}}
>
	<td class="tc-edit-field-value">
		@@.tc-edit-field-add-value.tc-small-gap-right
		<$keyboard key="((add-field))" actions=<<new-field-actions>>>
			<$transclude tiddler={{{ [subfilter<get-field-editor-filter>] }}} />
		</$keyboard>
		@@
	</td>
	<td class="tc-edit-field-remove">
		@@.tc-edit-field-add-button
			<$macrocall $name="new-field"/>
		@@
	</td>
</$let>
</$let>
</tr>
</$fieldmangler>
</tbody>
</table>
</div>
</$let>

I think these are the most relevant bits to our current discussion:

\function field.config() [[$:/field/]addsuffix<currentField>]

\function tooltip()
[<field.config>get[description]]
~[[$:/language/Docs/Fields/]addsuffix<currentField>get[text]]
\end

\procedure field-label()
<a class="nav general" to=<<field.config>> title=<<tooltip>>><<currentField>></a>
\end

<tr class=`tc-edit-field $(class)$`>
	<td class="tc-edit-field-name">
		<% if [<class>match[system]] %>
			''<<field-label>>'':
		<% else %>
			<<field-label>>:
		<% endif %>
	</td>
	<td class="tc-edit-field-value">
		<$keyboard key="((delete-field))" actions=<<delete-field>>>
			<$transclude tiddler={{{ [<currentField>]
				:cascade[all[shadows+tiddlers]tag[$:/tags/FieldEditorFilter]!is[draft]get[text]]
				+[!is[blank]else{$:/core/ui/EditTemplate/fieldEditor/default}] }}} />
		</$keyboard>
	</td>
	<td class="tc-edit-field-remove">
		<$button
			actions=<<delete>>
			class="tc-btn-invisible"
			tooltip={{$:/language/EditTemplate/Field/Remove/Hint}}
		>
			{{$:/core/images/delete-button}}
		</$button>
	</td>
</tr>

This is the table row used to render each field. You can see (more or less) how I’m using <<field-label>>, <<field.config>>, and <<tooltip>> to construct the link used as the field name. (I use <a class="nav"> rather than <$link> in link-list templates throughout my wiki; the whole page template is wrapped in an $eventcatcher that handles the navigation. But <$link> would work more or less the same way.)

And to render the field input from the associated field-type template, I’m using this cascade, which falls back to the standard editor if necessary:

			<$transclude tiddler={{{ [<currentField>]
				:cascade[all[shadows+tiddlers]tag[$:/tags/FieldEditorFilter]!is[draft]get[text]]
				+[!is[blank]else{$:/core/ui/EditTemplate/fieldEditor/default}] }}} />

IIRC that part comes straight from the core template. Since I’m using the existing Field Editor cascade to deploy my $:/field-type/... templates, I didn’t have to change too much here.

#83

Thanks heaps,

Yes, I was trying to avoid cloning this at such a high level as $:/core/ui/EditTemplate/fields but I think circumstances demand it. As you demonstrate.

  • I may add a little additional support with $:/tags/EditTemplate

I will work through it with a fine tooth comb as I proceed. Thanks again :pray:

2 Likes