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

#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
#22

Thanks for filling in the missing connection, @Scott_Sauyet!

Indeed, when a field houses a relationship that is in a sense bigger than (or just not neatly subordinate to) either of the component tiddlers, then the implementation of a third tiddler to function as the relational bridge/glue makes a great deal of sense. Genealogical relations are a great case in point. (And I love the granular recursive possibilities of having a tiddler connecting Person1 as a witness to the event of a ceremony whereby the relation of A to B was formalized, etc. where templates in A and B reach into such relations to show the connections…, and maybe our web picks up on another tiddler in which a diary entry by Person2 serves as evidence that [Person1 witnessed the union of A and B], etc., though doubt was in turn cast on that diary entry by… [etc.])

Having a relation-holding tiddler would of course not possibly make sense for most bibliographic field-value pairs such as:

bibtex-year: 2021
bibtex-pages: 188
bibtex-LCCN: 2038748676
bixbtex-series: Emerging Research
bibtex-volume: 54

… where the field-values have little to zero “there” there across records with the same value (let alone the same value across multiple fields, as when 54 might be the volume value for one tiddler and the pages value for another!)

Even when the field-value does have a coherent tiddler-like identity worth linking up (such as author), it would very silly indeed to have a tiddler for the book, a tiddler for the author, and a THIRD logically independent tiddler to store the fact that this-here book was written by that-there person ;). One would never want one’s “grip” on a bibliographic record (say, in porting it from one wiki to another) to leave behind info that has this “card-catalog” constitutive relation to the tiddler’s content.

Still, one might want a relationship tiddler for something like (say) citation connections or special-purpose notes. (The fact that brown2024 cites mingus2019 certainly is “baked into” the brown book, but it’s not a “core” data point, and it wouldn’t scale well to cram all such detailed connections into the primary tiddler!)

#23

I don’t find it all that silly. I think there are plenty of times when this would make great sense.

If you think of certain records/tiddlers as representing bibliographic entries, then sure, you want them to be as intact and comprehensive as you reasonably can make them.

But if you think of your wiki as a whole as (at least in part) a bibliography, then it might make more sense. So if the following two questions have equal importance in your wiki, then a well-normalized (in the database sense) set of data could well be the best structure:

  • Who wrote The Fragility of Goodness?
  • What works did Martha Nussbaum publish?

This helps to some extent with the “Martha Nussbam”/“Nussbaum, Martha C” problem, as we can have a dropdown to select Person when creating an Person/Work tiddler. And we can have an aliases list field on the Person tiddler. And if we have separate Citation records, then the appropriate format of the author’s name in that instance can be in its own field.

On the other hand, I don’t see any good reason for any such many-to-many relationships between a work and a bibtex-year. If I wanted context around the year – What other works were published that year? Who was born/died/married in that year? Etc. – then I would expect a virtual tiddler with a template that could answer those questions. The difference is that an author feels like an important entity. A year does not.

You know tremendously more than I do about academic bibliographies, so I may be talking out of my hat. But this idea fits with with how I’ve built a number of other wikis.

#24

And I suspect I would have spoken against compound titles, but in the absence of an approach to better support relationships it is a brave attempt.

Agreed

Here in my Infinite Topic No touch tags - or flags on tiddlers without editing or changing the tiddler - #102 by TW_Tones I recently raised;

  • The exception may be when we want more info stored in the relationship itself.

Essential to support accross tiddler relationships

As I belive I have some methods available now to build a robust set of inter tiddler relationship tools I have one remaining problem to be solved. This is well reflected in the concept of marriage.

  • If Mr and Mrs are married it is a relationship
  • However it should be time limited where possible
    • A marriage has a start date and may have an end date
    • What if we know they married but not when? we still want to maintain the relationship
    • What if we want to record when we recorded it?
    • What if we know the year not the date?
  • So there is sometimes, if not often, a need for relationships to;
    • Be maintained even with changes in one of the related tiddlers, or the relationship
    • Contain additional information

I am working on finding a solution to the issues around this right now;

Linking tiddlers via there title eg; ones spouse, yet storing additional information about that relationship.

#25

You’re dealing with the usual tiddlers and fields. For example:


title: title1

field1:value1

Then field1 is converted into a link.

Through filters or other programming methods, you can derive value1 from title1 and field1. You can also display this value1 to users via views.

I placed all information within the title. For example:


title:title1

title:field1

title:value1

title:title1 field1 value1

Since all these are titles, they are all links.

Currently, I cannot obtain value1 through filters or programming methods. I can only allow users to derive value1 from title1 and field1 via views.

My solution not only retrieves value1 from title1 and field1, but also obtains field1 and title1 from value1. Queries can be performed in either direction, similar to Prolog.

In Prolog, if the information a b c exists, you can query a b X to obtain c, or query X b c to obtain a.

Many phenomena share underlying commonalities.

For instance, tag1 can add supplementary information to title1. For example:


title:title1

tag:tag1

However, if we avoid using tags and instead employ wiki links, we can organize information in a similar manner. For example:


title:tag1

text:[[title1]]

We achieve the tag effect through backlinks.

For example, the following two approaches achieve the same effect:


tag:tag1 tag2



tag1:

tag2:

No solution is unique; alternatives exist for any approach. Multiple paths lead to the same destination. For instance, I replaced the outliner with the table.

My ssspc can also store field name and field value information while generating links. Thus, it aligns with this thread’s core point. It isn’t a field-specific solution. But for storing supplementary information, fields aren’t the only approach.

Therefore, my reminder in this thread is: if you require field values to be links, consider abandoning the field method and adopting the ssspc approach. This provides a ready-made solution.

My approach also qualifies as a no-touch tags solution.

My approach is to attach information to a tiddler in another location.

My approach allows attaching information to multiple tiddlers in bulk.

However, my approach is completely unrelated to TiddlyWiki’s existing information structure. Should I participate in TiddlyWiki discussions?

#26

@Springer

I just want to support the clarity in your first post, and also you using field-description. Using this prefix field- for all field-related data tiddlers can similtaniously be tags, field and contain other content.

  1. Should the fieldname solution be “direct” or “indirect”?
  • I think we should start with direct fieldname, but provide an option to migrate to $:/fields/fieldname if needed. The editor and other tools can be designed to look for $:/fields/fieldname first then fieldname. This allows us to use the system thus hidden form if the fieldname clashes with anything.
  1. Should users have fine-grained option to enable/disable “missing” fieldname links?
  • On second reading I think this is a good idea, especialy when parsed in the text field. But we need a local overide for some cases where the fieldname is multifunction eg the tags field may also open the/a tags manager.
  • Secondly we can have a more > fields tab to access them if disabled.
  1. What do you all think are the essential or most exciting fields about fields ?
    I think the latitude to define a field even complex attributes through field- prefixed fields. Here are some I want;
  • field-description what is it about
  • field-caption eg description field may have Description sentence case
  • field-tooltip appears on mouse over
  • field-values filter or list on what where to find values
  • field-type - this would point to a shared field-type whic may describe how to edit or display a color field, email address, short text, numbers etc… there will be far fewer field-types than fields needing definition
    • A field although it has a field-type may localy override a field-type-fieldname if it differs from a field-typ tiddler in some way, just by including that field-type-fieldname in a field tiddler.
    • For full and comprehencive field handling we would need to discuss what exists within a field-type tiddler, even if they are the same tiddler.
    • An important thing about field-types is they can be freely built and shared without use unless assigned to a field-tiddler.
  • The items you raise such as is_textarea/is_list etc… are better handled in reusable field-type-fieldnames be they in the field tiddler or in a shared field-type-tiddler

In a related matter it is clear we can say use an arbitary field to indicate it is a field tiddler eg field-description but this is somewhat arbitary, and one needs to remember what it is. I have come to the conclusion we need a defacto standard of a tiddler-type where we can indicate it is a field-tiddler, field-type-tiddler and other forms like contact, bookmark, organisation, domain, project etc…

  • However as discussed above one tiddler can quite easily have more than one role so perhaps tiddler-types (field) could be a list of roles, or we could use a tiddler-roles field?
  • We may then simple add another role or type to the list to create a field tiddler. The view template can then add a panel to any tiddler found to have the field role (or other roles). Such pannels can be turned off globaly with $:/config/design-mode=no
    • We can have a cascade option for loading the correct view template, body template(s) etc… for each role provisioned in advance, just use them as needed.
#27

I am not sure I grasp this. With my own deep knowledge to TiddlyWiki I feel I need to mature what we already have.

If it may help, when you go into tiddlywikis editor and have a custom field its editable towards the bottom of the page. Where you will see the field name in text as a lable to the field. This is where we were proposing having that fieldname link to a tiddler of the same name, like tag tiddlers (the tag pills) link to a tiddler with the tags name, at first missing, if you create a tiddler from a tag, we call it a “tag tiddler” and this topics idea was to also have “field tiddlers” and there in we can start to build additional features as we do for “tag tiddlers” that can have a caption, description, icon color etc…

  • However in the case of field tiddlers we can start to introduce field-types, selection filters and value and more.
#28

From the perspective of improving TiddlyWiki, there’s no point in discussing it further, because my solution doesn’t utilize TiddlyWiki’s data structure at all.

I fully understand what this thread is discussing. In the demo, clicking the field name brings up the field tiddler. Within the field tiddler, you can see all the values for that field, as well as which tiddlers contain values for that field. My solution can fully achieve this effect.

#29

Of course you should! You clearly have something interesting to offer.

But I’ve invested a reasonable amount of time in trying to understand ssspc. While I think I’ve grasped the basics, I also haven’t seen any use-cases where I would choose it over other TW techniques. Perhaps at some point I’ll have a moment of enlightenment where this suddenly makes sense to me. I haven’t gotten there yet, though.