[Proposal] Updating field handling functionality in TiddlyWiki

[TW_Tones]

I was trying to rework this concept of Virtual tiddlers to work on missing tiddlers. I wanted to hide at least the edit button, only on the missing tiddler, idealy by CSS introduced in a custom View Template.

<style>
[data-tiddler-title=`$(currentTiddler)$`] {
	.tc-tiddler-controls button:not(.tc-btn-\%24\%3A\%2Fcore\%2Fui\%2FButtons\%2Fclose) {
		display:none;
	}

	.tc-title {
		font-style: normal;
		font-weight: normal;
	}

	/* just for demo */
	border: 1px solid yellow;

}
</style>

• The above does not work

Unfortunatly this is not working, can someone assist please?

[etardiff]

I’ll try to take a look at the CSS, but I have to ask: why would you want to hide the edit button? IMO one of the most useful aspects of virtual tiddlers (at least under @Springer’s definition) is that, while a well-designed template may mean you never have to turn a virtual tiddler into a real one, if you do want to do so, all you have to do is start editing. In fact, a number of my cascades are designed so that virtual tiddlers use the same template I’d want that title to inherit to use if/when I actually add content… and a number of them do eventually get promoted when I find the time to fill them in. Making it more difficult to do that feels a bit counterproductive.

I’ll concede that if you’re using $:/virtual tiddlers in the way Mohammad suggests (i.e. as $:/temp tiddlers by another name) it might make more sense to discourage further editing. But I tend to think of “missing” tiddlers as tiddlers that don’t exist but reasonably could, and I think the way the core uses [is[missing]] supports this interpretation. A missing tiddler is a gap that you may someday want to fill.

[etardiff]

That said, I think using CSS to subtly (or not-so-subtly) highlight missing tiddlers (in ways that don’t involve removing the edit button ) is a good idea — particularly if you’re removing the cue provided by the italicized title link. You can do it by replacing [data-tiddler-title=$(currentTiddler)$] with .tc-tiddler-missing.

Edit:

@TW_Tones

The above does not work

From some quick testing, I’m going to hypothesize:

• Wikitext doesn’t get parsed between <style></style> tags, so your variable substitution isn’t happening.
  • [data-tiddler-title=<<currentTiddler>>] doesn’t work inside <style></style>, either — though I know that it is possible to use variables in stand-alone stylesheets - unless they have the static type: text/css, which disables wikitext parsing entirely.
• In a separate tiddler with the $:/tags/Stylesheet tag…
  • [data-tiddler-title=`$(currentTiddler)$`] doesn’t work here either, so I think substituted attribute values just don’t get parsed correctly in stylesheets.
  • [data-tiddler-title=<<currentTiddler>>] works if <<currentTiddler>> doesn’t contain any spaces; otherwise, it assigns only the first word as the parameter.
  • [data-tiddler-title={{{ =[["]] [<currentTiddler>] =[["]] +[join[]] }}} ] works for multi-word titles, as it wraps the title in quotes.
  • Of course, <<currentTiddler>> doesn’t help you in a separate stylesheet, anyway. So it’s lucky we have .tc-tiddler-missing!

Incidentally, this was annoying to test with your proposed styles: every time I found a working version, my edit button would disappear!

[TW_Tones]

@etardiff

why would you want to hide the edit button?

Simply, I am looking at providing the creation mechanisium rather than just dropping the user/designer into a raw editor. For example they may set the field-type from a dropdown list, which adds the field thus creating the tiddler but already in a working state. Perhaps also adding a suit of fields empty or default values.

• Although I mention missing tiddlers, the intention is to only do this for “missing field definition tiddlers” as per [Proposal] Updating field handling functionality in TiddlyWiki
• In my case I plan eventualy to allow custom prefixes and multiple redefinitions according to an optional namespace, so taking control of the creation process makes a lot of sense.
• I could make visible an alternate custom edit button so its intuitive, but hiding edit suggests something else is happening.

[etardiff]

@TW_Tones

I am looking at providing the creation mechanisium rather than just dropping the user/designer into a raw editor.

I think providing a purpose-built editor is a great idea, but I don’t think it needs to be mutually exclusive with allowing access to the familiar editor. Would you consider using the EditTemplateBody cascade to replace the default editor with your own? That would allow you to keep the edit button in its standard place.

I’ll admit I may be biased in this regard. As a habitual tinkerer I feel my frustration spike every time I encounter a read-only wiki in the wild… second only to editions that hide the Control Panel, or (god forbid) the Advanced Search. But I do think it’s important to allow people to edit tiddlers in their own wikis through whatever means they find most comfortable, though — even if that leads to them making sub-optimal choices or just staring blankly at your code.

BTW in case you missed it, I did edit my previous post with both a solution for you and my best guesses as to what wasn’t working.

[TW_Tones]

I have being thinking I would just leverage the missing tiddler state !has[tittle]through a standard view template to display a panel. No commitment yet to hiding the edit button, but a desire to establish a mechanisium to alter the buttons or other qualities of a tiddler in the story river through a dynamic stylesheet, in the view template. Without resorting to the other cascades.

• So not exactly a purpose built editor, more providing some canned tools from the view template.

[Springer]

@etardiff

why would you want to hide the edit button?

I don’t think this is the motive in @TW_Tones’ case, but I should note that one of my three types of virtual nodes is filter-expression tiddlers. So I very specifically hacked the edit template so that the edit button on those nodes is swapped out for a giant “no-enter” icon for these tiddlers, because creating them (with square brackets in the title) is a Very Bad Idea.

But yes, all the basic intuitive virtual nodes (tagname, fieldname, fieldvalue, date, etc.) would be designed to automatically display some glimpse of whatever’s automatically “already in there” about that node, while permitting a quick edit-mode move to add some additional substance.

Fieldnames are a great case! Every field name, on my view, should display as a link. It points to a node where a template automatically displays a “slice” of filter-driven info that’s broadly appropriate to a field as such. And ALSO some fields inspire us to say, Ah, it makes sense — here in this tiddler — to clarify the constraints of what should be entered into this field, or remind myself of to-do items for getting it to link up better with other things, etc.

[TW_Tones]

Of note is even without an edit button on missing tiddlers we get the following message due to $:/language/MissingTiddler/Hint

Missing tiddler “▭ test fieldname” – click <editbutton> to create

The edit button works the same way as the toolbar edit button.

[Springer]

@TW_Tones

even without an edit button on missing tiddlers we get the following message

“We” get that message… until and unless virtual-tiddler nodes become so much the norm for us that we ditch that “missing” message as redundant/misleading visual clutter.

Of course, I ditch that message partly because the button there is redundant: I have not disabled the standard edit button on the toolbar (unless it’s for filter-expression nodes whose titles would be illegal as tiddlers, and those should certainly not get the standard “missing” hint!).

[Springer]

With apologies for some overlap between our topics, I also have been wrestling with this NAMESPACE question:

@TW_Tones

• Prefixed ▭ eg ▭ fieldname, Searchable but we could hide them with and additional system namespace
• Prefixed $:/fields/ eg $:/fields/fieldname, only searchable in advanced search
• Or just fieldname = tiddler name eg fieldname, searchable and may conflict with tiddlers of the same name, especially if a tiddlername is used as a fieldname.

Since some of what I’ve been working on has a different emphasi-, I started another (but compatible) thread … mostly focused on the GUI I’ve developed for opening up fields as nodes where interesting things happen.

But YES, there are pros and cons to the “direct” approach of just making a tiddler called bibtex-title, and having that be the home for all the “meta” stuff about that field…

[TW_Tones]

Yes, I replied to Proposal: render fieldnames as links, and see what's possible with fieldname nodes! - #2 by TW_Tones and it contributes to this conversation.

Tiddlers with the name of a fieldname could have within it a set of fields named with the field- prefix like your field-description, allowing the tiddler to also be used for other purposes. Although a tool may be needed to be used to extract for reuse in another wiki.

An example may be domain, which can be a tag that defines what part of your life it related to eg work, personal, play, family, friends. the domain field can have one (or more of these domain names in its value). It would be a tag, a field definition, a source of field values and documentation about what a domain is.

I think this is the most obviouse next step

What ever we do in the future we do need to choose a default, and for the experimentation I am tempted to start with either direct fieldname or the aformentioned ▭ fieldname.

• Can only be (easily) created via the new fieldname process
• makes sence to start with an extewndable cascade for this.
  • Allowing us to change the default
  • Allowing the cascade to address fields via wildcards with a prefix or suffix seperatly.
    • Eg all -link fields can be handled one way and we dont need a definition for every field.

I also think it safe to aggree that all field related fieldnames be prefixes field- or ▭ , in part because we can then use a wild card prefix to list them all.

• if using ▭ we can make a tool to access the symbol (and others as they arrise)

[Springer]

@TW_Tones

I also think it safe to aggree that all field related fieldnames be prefixes field-

That actually sounds great to me! (EDIT: Just to be clear: There can still be some fields, such as “notes” that are put to good common use across field tiddlers and other tiddlers. I see your proposal as recommending a prefix for the kinds of fields that are specific to fields (like field_holds_longtext or field_data_type). Naturally the fieldname tiddler gets a modifier and modified field, and can take notes, tags, etc., as desired.)

(About the alternative other than field-: I wonder whether you see something other than a weird box for the special prefix you’re suggestion. Maybe it’s a platform or browser thing. The ▭ just looks like a blooper rectangle on my screen.)

@TW_Tones

I am tempted to start with either direct fieldname or the aformentioned ▭ fieldname.

Plain old “naked” fieldnames don’t actually seem to have much risk to me beyond being inconvenient in some “curated” enviroments… And for that matter it’s not too hard to add optional filters to my sidebar lists and search results, if I don’t want to see fieldname tiddlers there.

But even if we were to see strong reasons for a special prefix, I am still absolutely tempted to start the design work around the the direct (“naked” name) solution, because it’s so much easier to get proof-of-concept “intertwingularity” this way.

Once the power of the approach is demonstrated, then if we really want the fieldnames tucked into a special string, it would then be straightforward to build a few custom functions and cascade conditions (to get the “real” fieldname string into/out of the chosen prefix/suffix namestring padding)… We can cross that bridge when we come to it, knowing what kind of GUI and data structure feels right.

[TW_Tones]

I partialy agree here, but building a cascade from the beginning to determin the fieldname tiddler, even if only direct intialy, we allow others solutions to leverage it, and we are not opinionated.

There is another reason to develop a cascade solution, that is currently we dont have a way to say how to display a field, but we do have one to edit a field (see Field Editor cascade). By building a cascade for that we can lookup how to display a given fieldname such as by looking in the “fieldname tiddlers” field-viewTemplate field, also optional field-editTemplate field.

• That is this approach starts by building the infrustructure and setting some useful defaults.

I have just being experimenting with a cascade to determin the field definition tiddler title and the standard cascades dont do what I wish. It always results in a transclusion. Although I stand by the field-viewTemplate, field-editTemplate cascade idea.

• I will present a solution Post haste

[nemo]

@Springer

The ▭ just looks like a blooper rectangle on my screen

It does to me too, though maybe that wont be as big an issue in context of being used in TW?

An alternate unicode character perhaps:

⽥

It has a nice symmetry to it, looks like a table (not unlike how two field/value pairs would be, conceptually) with tails that imply more

Oh, and it’s unicode name (this is how I found it) has the word “FIELD” in it (one of only two in my slightly-outdated unicode reference. The other being field hockey. The existing suggestion is the generic “WHITE RECTANGLE” character)

⽥	2F65	KANGXI RADICAL FIELD
	1F3D1	FIELD HOCKEY STICK AND BALL
▭	25AD	WHITE RECTANGLE

(that said, I definitely have a preference to not requiring special prefixes, but having one standardised (or conventionalised) prefix definitely has it’s benefits. Part of me thinks it should just be X- as per old email header conventions. But apart from history and easy of typing, there isn’t much to it, and a more semantically valid unicode character makes a lot more sense)

[TW_Tones]

I would prefer to use ⽥ for a table tiddler, something I am working on.

• It risks being close to table, row/column and other ideas that are close to the concept of field, but not a field.
• I remain open to suggestions.

To be sure we are seeing the same thing

• I have looked for ages, and this seems right to me, but it is all in the air, in fact $:/fields/ maybe the most common outcome.
• Keep in mind it will always be alongside a defined fieldname eg ▭ description ▭ caption

### A global function to find currentField-definition 
* using the currentField variable used in the field editor and elsewhere.
* tagged $:/tags/Global

\function currentField-definition() [subfilter{!!currentField-definition-filter}!is[blank]] [subfilter{$:/config/fields/currentField-definition}] []

* Use the above and it can be overidden in any tiddler
* It will acess the filter in `$:/config/fields/currentField-definition` 
* or default to fieldname.

Note that whilst $:/config/fields/currentField-definition if used becomes global it can be a quite sophisticated filter such as differentating between system and standard fields etc...

[field-handling-definition.json|attachment](upload://c9ONwmeZbJB8cMNSgaTe4XiZ2aB.json) (806 Bytes)

Please suggest and edit if nessasary but if you use this "we will be on the same page/tiddler"

[nemo]

@TW_Tones

I would prefer to use ⽥ for a table tiddler, something I am working on.

ah more than obvious enough reason to not use it here then!

Perhaps multiple horizontal without the vertical divider - two different scales (I found the first first, but prefer the latter for ease of visibility):

▤	25A4	SQUARE WITH HORIZONTAL FILL
⊟	229F	SQUARED MINUS

Then tables could even be the crosshatch versions of the same for within-unicode consistency?

▦	25A6	SQUARE WITH ORTHOGONAL CROSSHATCH FILL
⊞	229E	SQUARED PLUS

Another thought, from a completely different visual thinking - this looks like the : that seperates the name and value of a field (there are many ‘colon’ variations, but most aren’t visually useful)

⍠	2360	APL FUNCTIONAL SYMBOL QUAD COLON

[TW_Tones]

It is possible to waste hours with this kind of thing.

• I have used ChatGPT to simplify this

I just thought we don’t need to have only one character so these are possible

• ASCII [█] or [-] or [- - -] or [ - ] or [_] or [~] or [ ~ ] or [~]
• Unicode “□■□ description” or [⸺] using a 2em dash

It is possible to use svg but not in our tiddler titles, it could be in our icon

• The icon will only be visible where displayed and not visible within the listing of such tiddlers.

[Scott_Sauyet]

I read this thread in a hurry in the flurry of catching up after a two-week vacation. Now that @Springer brought it back to my attention, I see great promise here.

I wanted to offer one possibility that I don’t think was mentioned above: should we have an entirely different type of tiddler for a field definition? As in the type field having a new option of Field Definition (text/vnd.tiddlywiki-fielddef) in the type dropdown.

This seems to be the top level of tiddler-handling differentiation, and, as it strikes me that we’d quite possibly want the editing and viewing interfaces optimized for such tiddlers, this would probably be the simplest mechanism to do that. It would also gives us an easy way to search for them.

I haven’t ever investigated how the type is used to give different edit/view templates, so I don’t know how much work this would be. But it might well be worth investigating.

[TW_Tones]

I will reply tomorrow with some background on this. thanks for contributing

[pmario]

@Scott_Sauyet

I wanted to offer one possibility that I don’t think was mentioned above: should we have an entirely different type of tiddler for a field definition? As in the type field having a new option of Field Definition (text/vnd.tiddlywiki-fielddef) in the type dropdown.

The type field is intended to be use like IANA mime-type. So creating new ones in an uncoordinated way, will make things more complex in the future.

There is an issue form 2014 at GH: Introduce vocabulary parameter to wikitext content type · Issue #345 · TiddlyWiki/TiddlyWiki5 · GitHub that you should read in its entirety. There even is a PR as you can see at the comment from buggyj.