Proposal: render fieldnames as links, and see what's possible with fieldname nodes!

#2

Great ideas @Springer and a number I too have explored. Like you despite a big conversation over here [Proposal] Updating field handling functionality in TiddlyWiki I am taking it slowly because I want to establish useful, core agreeable solutions not unlike your own.

There are other ways to handle fields, and I am also experimenting with these so any solution does not limit the other methods eg;

  • fields whos name matches a filter eg suffix[-link]
  • fields whos value has a protocol prefix value that begins http:// And https:// …

A comment on the direct/indirect approach, awkwardly I would say all of the above, including to allow a set of tiddlers to have their own custom set of “field definitions”. There are multiple ways to implement this and although complex to design will make them easy to use.

  • Such as a custom cascade for the “file tiddler” naming standard to be applied on a given tiddler or by default.
    • I really do favor a special prefix that is not a system one such as a unicode character. Still in standard search but clearly different.
      • We could do this for user tags as well.
  • A cascade for how to view a field in addition to the current how to edit a field.
    • Eg color is a number a swatch or both?

A clear discovery is if we created 100 fields they would possibly only have a dozen types such as short text, current text, text area, color, date/timestamp, title, title list, number etc… so I do favor an additional layer below called a field-type (you would set this in a field tiddler).

3 Likes
[Proposal] Updating field handling functionality in TiddlyWiki
#3

Currently I did only read your post to exactly this point and I felt I need to respond immediately. I do like the idea, because of the working demos and it seems you already use it.

I think we will definitely need some support from the core, especially because there are default core fields that are hidden by default, like modified and so on. Messing with them, has potential to cause confusion.

For my field-editor plugin I did create a "Warnign … " box, that is similar to the “Existing tiddler title” warning. So users, that want to create field names, that are reserved for the core, or do already exist in a tiddler, get this dialogue.

image
image1926×435 31.9 KB

@jeremyruston – IMO we should implement such a warning dialogue in the core. What do you think. (I’ll create a GH issue soon)

3 Likes
[Proposal] Updating field handling functionality in TiddlyWiki
#4

The core has a mechanism to define TiddlerFields descriptions. IMO we should try to reuse that mechanism, if possible. “lingo” tiddlers are .multids, translatable shadow tiddlers. They are “unpacked” at wiki startup.

Default Search

@jeremyruston – By default the TW does not search in field values. IMO we need to change that in the core, with a configuration option.

1 Like
#5

Hi @Springer may this plugin project become reality!

I was about to argue in favour of indirect, but you gave the most convincing arguments in your section on fields about fields. Being able to configure any properties of each field inside its own tiddler would soon prove invaluable. Moreover, it would allow to answer yes to your question about missing fieldname links, and even allow to compute fallback text if necessary.

Regarding display, what about displaying values with a special template rather than just the current value? For instance, the field value template may conditionally add some button to increment or decrement the value, or some link to a more complex editing interface. If the value is a tiddler name, could also display indirect values, like its caption or any relevant attribute. This value template could also be part of the tiddler that holds the field configuration.

1 Like
#6

please be aware this idea is closely related and a small part of a piece of work I am doing. I am trying to keep the design opportunities open but I have taken this a long way with a lot of research and poc offline. I am concerned the enthusiasm may overwhelm this process especially if we move too fast to core changes.

advanced field handling has being a concern of mine for a very long time. please see my thread in developers.

1 Like
#7

Since modified and created aren’t shown in the field-editing interface, I don’t see that my proposal/proof-of-concept really does anything to facilitate “messing with” them in any way (though I do think access to modifier and creator — as links to templated field overviews — will be especially useful in multi-user wikis!). My design also doesn’t make any automatic links to type or tags or text, since those also aren’t straightforwardly present in the usual edit-field array.

I should mention: I do in fact often find myself manually specifying a value for modified, using the “add new field” workaround. The “recent” sidebar list is useful for some audiences such as students who need to see what’s been added or changed. So I try to turn timestamps off before doing a cosmetic or technical fix. (Perhaps I’m refactoring some old “stupid” one-off style declarations, to move toward a cleaner css-class approach, but I don’t want students to think there’s really something new to see under “midterm assignment”)…

All that works fine if I’m really paying attention. But maybe I forget to turn timestamps back on before returning to substantive edits :grimacing: (so now I need to “touch” a bunch of tiddlers that I’ve updated during the lapse). Maybe I even tweak creator and created, if I actually made new tiddlers while timestamps were off). Or, I simply forgot to turn timestamps off before certain minor edits, and now want to back-date those tiddlers (to push them away from the top of the recent tiddlers list).

At any rate, your point is well-taken that some fields are more-or-less “off limits” for end-user use, and some kind of warning or extra step makes sense before allowing edits to them (even independently of my current experiment in design).

1 Like
[Proposal] Updating field handling functionality in TiddlyWiki
#8

This is interesting and important. To make the breadcrumbs clearer: the mechanism is through language tiddlers such as this one: $:/language/Docs/Fields/stability whose text (in English) is

The development status of a plugin: deprecated, experimental, stable, or legacy

Of course, a tiddler named “stability” or “priority” or “catalog-number” (or named §/stability etc.) could integrate with this approach by creating and/or modifying tiddlers in the $:/language/Docs/Fields/ namespace to hold the explanation of that field’s contents.

If what I’m calling field-description were the only significant meta-data for fields, then I think this would make sense. But if we realize that fields may want to have quite a few attributes, the proliferation of one-off tiddlers (to hold this and that attribute) would seem a very inefficient way to connect all that info (and not all would need the “language” approach). Separate system-space tiddlers for each attribute would also make it more difficult to port a solution. On my biblio site, I can imagine saying: “Here are the plugins and the custom fieldname tiddlers you need” and dragging the fieldname tiddlers would carry along all of the field parameters carefully configured to display (with tooltips etc.) as intended…

On the other hand, the language-tiddler approach is clearly fantastic for plugins or other tools that want to be open to further translation modules.

#9

I believe most language tiddlers are transcluded so we could place within them a redirection to a field- in the field tiddler. this will also indicate the field is described in the field tiddler.

I agree on the consolidated handling of field definition, but let us not be over zealous and still integrate with the various settings already available such as on a field tiddler let us choose to show or hide that field from the editor.

this leads us to consider the template used on field tiddlers and I believe it should use a tag system like the view template, to allow hackability, thus perhaps is a new cascade “field tiddler view template”.

  • this makes me ask what also of a “tag tiddler view template” and “missing tiddler view template”?
#10

Great conversation!

Do you mean a new cascade for how fields themselves display, either in edit mode or when transcluded as fields? Or do you mean a new cascade for how the story river shows the body of a tiddler [or node] when that tiddler is a fieldname (or specially-prefixed fieldname)?

It seems the second of these isn’t really necessary — the cascade for how the body of a tiddler (/node) is handled (plus view templates themselves, which can be conditional) already give us all the necessary tools.

But I’m intrigued by the idea of fields themselves being displayed and edited through cascade conditions. We already have a few different ways that fields display in edit mode (type is a drop-down, color is a color picker, tags have their proprietary edit interface; created/creator/modified/modifier are suppressed altogether in edit mode… and lots of us have been using longer textarea input boxes, invoked by some condition). Having a cascade for all this would open up room for people to develop various additional interfaces for editing and displaying (or hiding) fields (date/time pickers with certain conditional defaults, drop-downs based on a list condition articulated in the fieldname tiddler, etc.)

With your comment about new cascade for tag (tiddler?) templates, I again am not sure we need anything additional for how the tiddler displays (given the standard cascade for how body of tiddler/node is handled, plus conditional view templates)… But how tags themselves (tag-pills) display might benefit from a cascade… In off-the-shelf TW, the only variable is whether the tag has an assigned color, right? (I’ve also implemented italics text on tags that have no tagname home tiddler, and I often use ben webber’s tag-count solution.) Adding a cascade there might allow people to have tags whose style “pops” in response to certain conditions (tasks not done under this tag), or tagpills styled according to some variable (color-gradient that tracks quantity of tiddlers under that tag, etc.)

While we’re at it, being able to control the order of tags as displayed might be responsive to cascade conditions, just the way the order of items under a tag responds to a hierarchical array of criteria.

For the “missing” I’m not yet seeing why/how we would need a new cascade… Say more about what you have in mind, @TW_Tones?

It seems to me that we already have full control over how nodes display in the story river. In particular the $:/tags/ViewTemplateBodyFilter cascade can notice that a node !has[title] (to use @etardiff’s nice compact filter condition). Subconditions for different flavors of so-called “missing” tiddlers overlap in various ways with other aspects of that central cascade, so a separate cascade might be confusing. (With just one cascade, I can decide whether to catch prefix[$:/] before or after !has[title] etc. … If there were multiple cascades — with a separate one for the “missing” nodes — it seems we’d risk redundancy or lack of flexibility, no?)

#11

@Springer I am still on the road so my answers will be less sophisticated.

in my last reply the cascades I was thinking of would be equivalent to the view template tag and cascade, providing a tag for elements to be displayed on tag/field/missing tiddlers so we, multiple designers, can introduce features to these tiddlers without core modifications and the possibility of solutions working together.

  • an equivalent can be implemented through the view template with conditions in those tiddlers but seperate cascades would make it more visible and adaptable.

I very much hope to have field view and edit cascades and it makes sense to use the existing field editor cascade (edits fields only) inside this to keep it consistent. with field tiddlers we can extend field handling to field-type, values, validation, labels and more. but the same can be said for viewing fields, a cascade that established how to display the values.

  • here we note that if a field definition tiddler exists the cascade will look to it for information to edit or view that field, otherwise fall back in the cascade.

Of note is currently in tiddlywiki we need bespoke code to display fields in the view template, I want the tools to to support this including presenting fields in forms. Making it easier to display and use fields. here I need to introduce a new mode in in tiddlers in addition to view and edit. what I have called update.

  • if a wiki is not read-only allow all custom fields or one at a time be placed in to edit mode from the view template
  • to do this there is a need to introduce a concept called modes, we are familiar with view and edit, perhaps even read only, but not yet update.

interesting ideas about more control into tags, I will have to revisit soon.

well first on missing tiddlers a cascade could determine if it is a tag, field or other to be imagined tiddler type and display content. now let’s say you com along with some new missing tiddler concept you just add the tag to be included on the missing tiddler and no need to change shared tiddlers.

  • in the world of field handling we already want to add to the missing tiddler cascade to handle field and tag tiddlers.

in closing I have no problem using the existing cascades to invoke further cascades after all arguably that is best practice. However when you do, you make a choice and you have to live with it. eg the body cascade will restrict you from altering the buttons on a tiddler, with CSS exceptions.

  • Mohammads virtual tiddlers may need to change the story cascade not the body cascade

please call out any ideas of yours I have not responded to.

#12

Be aware, that cascades work well in View- and EditTemplates but they do not scale well inside list-widgets in long lists. — Just to be sure.

#13

Fields already have their own cascade to show different templates in edit-mode. See: Customizing EditTemplate field rendering

All existing cascades can be found in the $:/ControlPanel → Info → Advanced → Cascades

That may cause a performance hit. Non interactive tag-pills are fine. But the tag-macro activates an event-listener that handles the tag-dropdown, for every tag-pill that is visible. This has the potential to considerably slow down browsers on mobile devices.

So if this is considered, there needs to be some help from the core code itself. There are some JavaScript functions, that can help us with everything that creates a link or dropdown. Those functions are available since 2016 / 17 / 19 and 2020 on many mobile devices. So we need a fallback to the existing behaviour.

That’s an internal JavaScript problem, which has to be fixed in the core first. At the moment it can not be guaranteed, that the tag order is consistent with all browsers. That’s why they are sorted alphabetically by default. Tags are internally stored in so called objects. How those objects store their elements can be implemented differently depending on the browser. – To fix that we need JS functionality that will be available for v5.4.0 with ES2017

1 Like
#14

Yes — though what I’m saying is that this is already very well do-able with the existing cascade. That is, the cascade conditions tagged $:/tags/ViewTemplateBodyFilter can target so-called “missing” tiddlers, and subsets of these. There’s no need for a separate cascade.

In developing my quick-demo model of virtual tiddlers, I eventually decided against using the central body cascade for various virtual node conditions (“missing-tiddler” nodes), because I realize that usually I want a view template (for tag nodes, or for fieldname nodes) that behaves pretty-much identically for actual-tiddler nodes and virtual-tiddler nodes. (Rarely would adding a color or list-order to a tag mean that I suddenly don’t want my nice automatic tag overview!) At most, the view template employs a simple conditional frame like <%if [<currentTiddler>tagging[]then<currentTiddler>!hide-tag-overview[yes]] %>. But still: in principle the existing cascade could handle all the different “missing-tiddler” conditions.
I have approached fieldname tiddlers similarly, and even certain fieldvalue tiddlers (such as any node that corresponds to a modifier name) — that is, I’ve found it makes sense to apply a conditional view template so that the automatic intertwingularity template “plays nice” alongside whatever proper content the tiddler might serve up, once it comes into existence as a tiddler.

But if one did want to work directly with the cascade, it’s easy to integrate cascade conditions for “it’s not actually a tiddler but it’s a tagname” or “it’s not actually a tiddler but it is a fieldname or prefix+fieldname” node. (And I don’t see how a separate cascade would be helpful.)

…

THEN AGANI: On reflection, I realize perhaps what you’re suggesting could be as simple as taking the current minimalist “Missing Tiddler” hint, and making it potentially the locus of a cascade, so that the “missing” message itself can be more informative (even if it doesn’t make sense to include the full template-like stuff that might be equally good as its own view template).

It might be nice if eventually the core offered a basic cascade of helpful options; so that “out of box” users would see text like There's no tiddler here for [nodename], but [7] tiddlers are tagged with <<tag>>. Click _edit-button to create … with variations on that message for (certain) fieldnames, certain important fieldvalues, etc.

3 Likes
#15

I’ve updated the demo to include access to the core’s field definitions (in $:/language/Docs/Fields/ namespace), and to include more info and cues to distinguish the core’s special fieldnames from other fieldname nodes. As always, a fieldname in italics indicates there’s no tiddler there (just a virtual node with automatic template elements), while regular roman font signals that the destination node is a real tiddler.

Hovering over a fieldname (in edit mode) includes a tooltip with the field’s description — preferring the description as entered by the user in the relevant fieldname tiddler, else pulling from the shadow language tiddler as below:

image
image840×560 51.3 KB

View templates for fieldname nodes have also been improved.

So far, this solution is 90% GUI — just making for better access and “intertwingularity” among elements and bits of info that are already “in there”. I hope that playing around with this interface inspires people to participate more in the discussion of what fields can be, at their best. :slight_smile:

3 Likes
#16

Just started trying this in my Kansas Railroad wiki and am liking what I see. I need to play around with it some more, but am very impressed so far. Seems to work like a charm. Thanks for working on this. I can see where this would be a big help in field maintenance and, perhaps, wiki maintenance.

1 Like
#17

Thanks again for this! It is working great in my railroad wiki. I’ve customized the template to make the list of values scrollable (many of my fields have a large number of values) and I used the pagination option for the dynamic table. I’m very happy with it. Thanks.

1 Like
#18

This is a good idea. I opted instead for having a default limit, but a scrollable list (say within a height-limited pane) may be the best of both worlds.

2 Likes
#19

My approach does not uses TiddlyWiki’s field solution; instead, both the field name and field value are placed within the title.

As a result, both the field name and field value become links.

#20

I admit to being baffled by “both the field name and field value are placed within the title” … the title of… what exactly? If I have a tiddler with, say, 9 substantive-content fields beyond title, text, and the automatic ones (common for a bibliographic wiki), your solution would be different. It would use … 9 additional tiddlers … Or 18 tiddlers? Or one tiddler with 9 field-value pairs packed into a long title, or…?

Also, I don’t understand how “both the field name and field value become links” by being part of (one) title; the title of a tiddler itself can be treated as a link, but doesn’t naturally articulate into separate links for component parts (without some additional fancy footwork).

If you’re not using fields at all, I’m not sure that yours is really a comment specific to this thread (which is very much about fields), but you do seem to be suggesting that there’s an approach different from using fields but somehow comparable and useful to you, so I’m intrigued (as well as confused) by your comment. Say more?

1 Like
#21

If I can summarize what I got out of an exchange with @tomzheng in that thread a few months ago, he’s building a system that allows him to parse structured titles to declare relationships between tiddlers, which might then also let you derive additional facts. So for instance the title John Adams was married to Abigail Adams would be parsed by an explicit married to rule and assert a relationship between the tiddlers John Adams and Abigail Adams. His idea was that this would allow some recursive parsing to build up larger such relationships; his example was “Tom’s sister is Jerry’s sister’s teacher”.

While there are some very interesting ideas in there, I was never convinced that I would ever have any need for such a tool. And no, I don’t see that it has anything to do with this thread.

1 Like