[Proposal] Updating field handling functionality in TiddlyWiki

[nemo]

@etardiff

if I have content in the “author” tiddler, and you have your “author” tiddler set up for a certain field configuration, I can’t import your “author” without losing my own content. Instead, I’d have to open it and manually copy all the relevant fields into my own version of the tiddler.

That’s a good point, and my first thought was that the ‘Export Tiddler’ menu item could (optionally) go to a more complex export dialog, where fields could be selected/excluded from the export - and then from there could be dragged with just the specific data being exported.

My second thought was that on import, the same thing - if there is a conflict between the import data and existing data, that it prompt for which fields to keep from which side of the conflict.

On reflection, both of those are arguably good things to have in general, and whilst solving this problem, are not specific to here.

@etardiff

I think the fact that you can typically “copy” a configuration just by dragging some plugins/system tiddlers — without altering any of your own content tiddlers — is a major selling point of TW. I think it’s risky not to follow that precedent — not to mention potentially confusing for users.

I think that’s a good point!

@TW_Tones

using fieldnames based on existing tiddler names, independant of field handling

I expect this is the sort of thing I’d end up using a bit, though I dont have examples to mind just yet. Your example however doesn’t resonate with me, since my instinct would be to have the field name be the more generic thing (“sister”) with value “Cathy Smith” (indeed, values as a list since there may be multiple sisters. I do see the simplicity and value of having ‘Cathy Smith’ as the field name though as a discovery mechanism!

@TW_Tones

• fieldname = name of field tiddler “fieldname”
• fieldname = name of field tiddler “▭ fieldname”
• fieldname = name of field tiddler “$:/fields/fieldname”

I wonder if another solution to the field-information/tid-information overlap described above, is an “excise” mechanism to convert the field values from a “fieldname” tid to a dedicated “▭ fieldname” or “$:/fields/fieldname” tid?

[etardiff]

With apologies for the slight digression, @TW_Tones, and in hopes that this is still at least somewhat useful to you…

@Springer

These may have somewhat different needs, actually. Whatever view template we want for empty-node tagnames may well also want to show up by default on tag nodes that are tiddlers.

I think this is an important point! I use some similar ViewTemplates for tags and other field-based connections, but I’ve found it easier to apply those with the $:/tags/ViewTemplate rather than the ViewTemplateBody cascade. That way, if I decide to add some text content to a previously-empty node, I won’t lose the visual summary of its (pre)existing connections. A “missing” tiddler may thus display a custom “body” template, or a ViewTemplate summary segment, or both, or neither, if I’ve never referenced it before at all.

@Springer

Beyond the old-fashioned “missing/lost links”

I don’t use backlinks[] much myself — I’ve found it can get slow in large wikis, and many of my links get stored in non-text fields anyway — but I can imagine it being useful in a ViewTemplate segment or even a missing tiddler template, particularly if it’s a node that might merit its own content.

@Springer

Filter expressions, of course, are a totally different kind of node, and a bit of a niche interest…

This is a fascinating application, and not one that had ever occurred to me. I’m not sure I have any immediate need for it, but I think I felt my mind expanding a bit, just seeing it.

Do you find that it replaces standard filter search for you? I was going to suggest adding a link from the search results to the relevant node, but I see you’ve already done that.

[TW_Tones]

@Springer

a whole cascade for non-tiddler nodes in the story river — sounds more semantically appropriate than stuffing conditional logic, and substantive template transclusions, into the missing tiddler hint!

Exactly my approach. Nice to know your adventure here.

@Springer

have it show up only when there’s no relevant automatic-template content at the node.

Exactly. So is this a story tiddler cascade to control buttons, or a View Template Body cascade for just the content?

I may have to put filter and extended “virtual tiddlers” aside for now in this project. Although I stand to be corrected. This may be a good place to discuss Create and Use of Virtual Tiddlers

@nemo

I wonder if another solution to the field-information/tid-information overlap described above, is an “excise” mechanism to convert the field values from a “fieldname” tid to a dedicated “▭ fieldname” or “$:/fields/fieldname” tid?

I am not exactly sure what you mean by excise. Please tell me more. But just so you know I have a number of ideas here, the one I like the most is hiding this in the existing UI.

For example this is how I am crafting it;

The fieldname is tied into a link to a missing tiddler, clicking on it creates the missing field tiddler “▭ New field” (as an example).

• In this case the prefix indicates it is a field definition tiddler.
• Perhaps the way to define the field is to set the field-type field on the tiddler (rather than edit to create).

@nemo

Your example however doesn’t resonate with me, since my instinct would be to have the field name be the more generic thing (“sister”) with value “Cathy Smith” (indeed, values as a list since there may be multiple sisters.

This was just a quick grasp at an example to illustrate, and although not compelling on its own. I think in the fullness of time examples that are compelling may be found. Although this is where its nice to handover a capacity to do something and let others explore the “innovation space”. Sister may be a bad example, it should be sibling with the Cathy Smith tiddler providing information about the “personal pronouns”.

• My suspicion is such use cases will emerge when it comes to bilateral relationships". For example when the relationship is different going in a different direction.

@etardiff

I don’t use backlinks[] much myself — I’ve found it can get slow in large wikis, and many of my links get stored in non-text fields anyway — but I can imagine it being useful in a ViewTemplate segment or even a missing tiddler template, particularly if it’s a node that might merit its own content.

Actualy backlinks[] links[] and now transcludes[] are operators that may be able to shed light on what a “missing tiddler” is about. A fieldname could be (placed) in the list field of a tiddler “my fields” to actualy define it as a field definition tiddler.

@Springer I assume a virtual tiddler, define witrh a filter as title can

1. List the results of the filter and
2. Have a button to create a filter tiddler, as available in Advanced Search > Filter > Dropdown

[EricShulman]

@TW_Tones

a button to create a filter tiddler, as available in Advanced Search > Filter > Dropdown

The TWCore currently has 14 shadow tiddlers containing pre-defined filters. Each shadow tiddler is tagged with $:/tags/Filter, and contains a filter field (the saved filter syntax) and a description field (the text to show in the $:/AdvancedSearch > Filter dropdown list).

To make it easy to add filters to the dropdown list, add TiddlyTools/Search/SaveFilter to your TiddlyWiki. This tiddler is tagged with $:/tags/AdvancedSearch/FilterButton, which adds it to the other buttons that appear next to the $:/AdvancedSearch > Filter input field.

When you press the save filter button, it displays a popup for you to enter a tiddler name, edit the current search filter syntax, and add description text. By default, filters are saved with a prefix of $:/config/TiddlyTools/Filter/..., but you can edit TiddlyTools/Search/SaveFilter to change the config() definition to any other location you prefer.

enjoy,
-e

[nemo]

@TW_Tones

@nemo

I wonder if another solution to the field-information/tid-information overlap described above, is an “excise” mechanism to convert the field values from a “fieldname” tid to a dedicated “▭ fieldname” or “$:/fields/fieldname” tid?

I am not exactly sure what you mean by excise. Please tell me more. But just so you know I have a number of ideas here, the one I like the most is hiding this in the existing UI.

For example this is how I am crafting it;

The fieldname is tied into a link to a missing tiddler, clicking on it creates the missing field tiddler “▭ New field” (as an example).

Perhaps “excise” is not quite the right term here (esp since it has a meaning within normal tid editing). Anyway, idea is that if a tid exists named “New field”, and recognised as a field definition tid via it’s own “field-type” field (and perhaps others?), then just the bits that define it as a field definition tid could be elevated out to “▭ New field” style - the new one having the fields that are relevant to it being a field definition tid copied over, and the normal tid fields remaining with the original. (Whether the field-type (and others) fields are removed from the original, or remain (but ignored because of the precedence of the new field definition tid), is a matter of lesser importance. I’d be inclined to leave them be, and those fields within the ‘New Field’ tid effectively become “shadow field definitions” - they exist but are unused.

@TW_Tones

although not compelling on its own. I think in the fullness of time examples that are compelling may be found

That’s my feeling on the matter too. Tid’s being able to define fields to multiple other tids via field definitions, feels like it’ll enrich the interconnectedness and organisational possibilities of TW.

[TW_Tones]

Thanks @EricShulman I seem to have lost my nicely crafter responce. I think this could be a button on missing tiddlers that have a title equal to a filter as per @Springer’s filter titles idea.

Be aware I have two cats that keep tring to stand in front of my screens, keyboard or on my lap. So dont be supprised if some typos slip in. Or worse as my spellchecker is not working in my app window to talk.tiddlywiki.

@nemo see Virually merging two tiddlers? Triddler stacks and form of monkey patch which is complemetary and somwhat related to your approach perhaps?

[Springer]

@etardiff

Do you find that it replaces standard filter search for you? I was going to suggest adding a link from the search results to the relevant node, but I see you’ve already done that.

My habit is to hit the keyboard shortcut for advanced search, and use the filter tab. Then if I realize I’d like the big overview afforded by a dynamic table (rather than a mere list of links), I hit the button to open the filter expression as a node in the story river. I can keep the node open as long as I want during a session, but it never becomes a real tiddler.

The other place I’ve tried to embed the “open filter expression as node in story river” option is in the filter-pill dropdowns by @TW_Tones. It works great for one-off filters, but still needs more development to pass the granular filter to the tm-navigate widget, if the filter-pill is itself embedded in a list widget.

[TW_Tones]

Off Topic: Just as we have the ability to find transclusions and back links thoughout tiddlywiki including text fields perhaps an operator that can find and return filters as delimited by [ ] but also if starting with :runprefix and extending between " quotes " including ' and now back ticks.

• I expect relink has already solved this.

[TW_Tones]

I will just note there are two other smart approaches to field handling I do want to facilitate or at least not hinder as a result of improved field handing these are;

• wild card based handling
• protocols in the field value

wild card handling is where you may use a filter to invoke custom handling such as with a fieldname prefix or suffix eg all fields ending in ‘-link’ or prefix ‘name-’

by protocols in field values is when the fields value names a protocol the most common examples are the url protocols such as http https mail to etc…

• that is field handling is driven by something in the value rather than the name of the field
• this can free up the field names to be flexible and thus descriptive

the issue becomes determining precedence

Also note @pmario addresses many of the issues about implementation for fields in the view template HowTo: Use Custom and Complex ViewTemplates (Tagging and Cascade)

• Of particular note to me is his use of the info tab

[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)