[Proposal] Updating field handling functionality in TiddlyWiki

Developers
, ,
#55

Understood, but thy are like IANA media types, right? Or have we gone through a formal registration process for

  • text/vnd-tiddlywiki
  • text/vnd-tiddlywiki-multiple
  • application/x-tiddler-dictionary

? I was simply suggesting that it might behoove us to add one more, chiefly as a way to give these field definitions their own fairly different UI than plain tiddlers, CSS files, PNG images, etc. This was a spur-of-the-moment proposal, and I certainly haven’t thought through the implications.

I have now read that thread, which I hadn’t seen before, and glanced through the changes @buggyj suggested. I didn’t find the actual PR, though I didn’t look hard. Was it merged? I certainly would not object if this functionality used a vocab parameter to vnd.tiddlywiki rather than an entirely new type. (I have no idea if the registration process includes descriptions of all such parameters.)

But more generally, I couldn’t tell from your message whether you were trying to express an objection to my suggestion, or just provide some background on related discussions. “In an uncoordinated way” makes me think it was an objection, but I was thinking that this would be an upgrade to the core, perhaps for 5.4.0, perhaps even later. I would assume we would have time to coordinate this, and if we do register our internal MIME-types, we would have time for that.

But again, this was a passing thought, not a deeply considered suggestion. It may be unusable for all sorts of reasons.

#56

The preview TW is at: http://tw5vocab.tiddlyspot.com/
The repo is at: GitHub - buggyj/TiddlyWiki5 at remotes/origin/vocabs

It’s from a TW beta version from 2014

It was an objection about a new type.

I think the discussion Proposal: render fieldnames as links … and here IMO all will “hit the same road-block” as my thought experiment: How could system-fields look like with …. I think it’s exactly the same, from an “implementation standpoint”.

TLDR; Jeremy’s objections Fields with meta data are tiddlers.

We did not officially register them, which we probably should. But I think that’s a rather “tedious” process.

I do not really know, why @jeremyruston did create text/vnd.tiddlywiki-multiple instead of introducing a text/vnd.tiddlywiki; vocab=multiple type, which probably would have been more in line with his proposal: Introduce vocabulary parameter to wikitext content type

But I think it is not too late.

#57

Hm, I propose this one:

§

As far as I know TiddlyWiki makes no formal use of it yet.

The § character means “section” and has a nice semantic relationship to the idea of a field as a sectioned-off element of a tiddler.

For me, whatever we use has to be readily accessible via keyboard. The section character is opt-6 on a mac. Not sure what it is on other platforms, but it’s supported in most fonts and isn’t at risk of turning into an inscrutable □.

#58

I don’t yet clearly understand what the objection is (or what the objection is directed against). Happy to hear from @jeremyruston … Fields can be mere strings, just like tags can be mere strings. Nothing about allowing for field-tiddler development prevents anyone from continuing to use fieldnames as “flat” strings.

But nothing prevents a fieldname from becoming the name of a tiddler, which is home to whatever content — including fields — we find appropriate. (And some likely common patterns can shape best-practice discussions for what kinds of attributes we are likely to assign to fields as such, including whether to converge on some naming practices…)

In a way, preventing such dimensional power for fields would be resisting the TiddlyWiki philosophy (everything is — or can be — a tiddler). But I suspect I’m not understanding the context of the objection well.

#59

Alt-21 on Windows.

It’s more complex on Linux, because of the many flavors and various keyboard designs, but it’s available with at most a few keypresses on any of them.

1 Like
#60

@Scott_Sauyet I thin @pmario starts to illustrate the complications with the type field, I think there is a resonable argument unless we are dealing with mime types and other content variaents it is best to stay away from the type field. I have done a number of deep dives into it a few times, the following was my conclusion.

  • Type is more abour mime and system types for the content
  • As a result I have consistently used another field object-type to differentiate between tiddlers with different functionality. I use object because it is often a general term for what a tiddler is eg contact, recipie, chapter etc…
  • Perhaps start another toipic if you want to explore the type field further

Perhaps I will soon illustrate the following but I do think there are some missunderstandings here;

  • We dont need to enter these field namespace from the keyboard, as we may control the creation process
    • Most unicode can be entered at the keyboard, you just need the code
    • Making these hard to create without using the creation process is part of its value
    • clone or title copy paste is a simple work around if you have already one tiddler with that title
    • All the characters after the “symbol chosen” are searchable in standard search

Missunderstanding about standard and system fields

Discussions here and over here;

I would contenst some recieved wisdom here. It is easy to reuse standard and system fields with impunity in most cases. for example it dose not make sense to reuse plugin-type or modual-type, and I always leave the created and modified names and dates for the system to maintain.

But not withstanding those, a field means what you intend it to in the context in which you use it.This is one reason I make use of the object-type field to set a type (used) of tiddler. You can always scope the field and even its meaning as belonging to an object-type or another indicator like a tag. This permits reuse of existing standard and or system fields.

  • A wise designer always qualifies a field eg; if the already depend on the color field they will use an alternate border-color, or object-color etc…

The display and edit of fields. There is no problem if a designer makes available an existing field to drive some process, for example the modifier. Even if tiddlywiki allready provides some handling eg in the subtitle, the designer can introduce it to the view template.

The full argument may run down some rabit holes but I do want to make the point there are very few cases where people want to reuse standard or system fields and when they do in many cases it makes no difference.

Conclusion

Keep the existing use of standard and system fields in mind but there is largely no need to treat them much differently when adding field handling.

  • If anything this is a key argument for field tiddlers to have a prefix
  • It suggests we could document the existing fieldnames more.
#61

I tend to agree. I do see value in signposting whether (and how) a given field name is already used by core. But outside a few instances in which “misusing” a field may have unintended side effects (like the class field, if you happen to have a CSS class that matches whatever content you put in the field… guess how I found that one out?) I don’t think there’s much harm in reusing fields like name, source, or even subtitle for other purposes. So I support your conclusion here:

Re: the namespace issue…

I know you already know my thoughts on using unicode characters in config tiddler titles (to wit: please don’t), but I read your response in another thread right after I read this one and couldn’t help but note some irony…

Why make accessing these tiddlers intentionally difficult? (Let’s set aside the issue of whether you find it substantially more difficult; I, at least, would find it frustrating.) Don’t we all have the god-given right to screw up our own wikis? :stuck_out_tongue:

#62

I can imagine one kind of fieldname solution that tucks much of its mechanics “under the hood” so that things are handled according to a careful system.

I don’t imagine that I would myself prefer that kind of solution. I prefer a transparent approach: “Look, here are some tiddlers whose names are fieldnames, and here’s how adding fields to those tiddlers opens up possibilities!”

Some visual distinctions, and some hierarchy of obviousness, can still be wise. I’m thinking of how system tiddlers look different and don’t appear in searches until you use the advanced-search tab. But if someone told me that I could only create a system tiddler by going through a curated helper-interface… and that this was for my own good … :grimacing: I think the power of fieldname tiddlers (and their fields) is comparable. We want to hammer out reasonable levels of protection against accidental mangling, and reasonable “handrails” for enabling people to move around efficiently. But not much more than that.

I think this whole process (of reflection on the power of fields) may lead us toward some basic tweaks that reduce the risk of this kind of problem.

If choosing a fieldname (in the edit-fields interface) means choosing something within a space that easily triggers some smart css (following attributes of fields), then it would be easy to add gentle-warning formatting/icons for “special” fieldnames.

1 Like
#63

First this is all moot, because you choose the prefix. Do as you wish.

Also we already have specific methods to create tiddlers, use the new tiddler button, follow a link as well as with tags (add to a tiddler then click on the tag pill) sure you can create a tiddler of the same name but it will not be a tag until used as a tag.

Note: Thanks @Springer and @etardiff for you contribution and rigorous debate :nerd_face:

Keep in mind my proposal keeps the fields visable, searchable , editable etc… but it also allows us to quickly identify them as would $:/fields/ prefixes

  • My point is we implement a method where you can choose both globaly or fields within for specific tiddlers, or class of tiddlers. I am not proposing the reduction of any feedoms I am expanding them.
  • I think it is safe fore us to prototype this and you can try it and I expect see my proposal is not proscriptive.

Ok, Now create a shadow tiddler, you may not even have a “curated helper-interface…”. Currentlky that is not strait forward but we do build plugins to achive this.

  • Not very difficult :nerd_face:
    • We could detect its a field and offer an option even if missing
  • In part the reason is so as to ensure the “handling clicks in” when such fields are created. For example in my current model one can determin the fields namespace by including a field, defining it, in every tiddler. This allows the link, the open to edit field and subsequent edit and view templating to be aware of these custom field namespaces with no further configuration.
    • Enabling a set of field definitions scoped for a given solution or plugin
    • thus Supporting the reuse of fields within a scope
  • If I just created a new field definition eg $:/plugin/PSaT/concactDB/fields/fieldname or &fieldname, without going through a supported method, there would be need for hidden information to make it work. I am only suggesting encoraging the user.

also

@etardiff
My proposal actualy allows us to generate field tiddlers for existing fields, independant of current handling. We can tag these to group them, we can provide a cutom view and document them.

For example the aformentioned class field

  • class field “This field has a default use and should be avoided” It allows the naming of one or more class names, which will be alpplied to the tiddler on which it has a value.
    • give examples
    • propose use anyname-class or function-class etc… for custom class fields.

If you are still not persuaded;

  • Remember its your choice (or someone else who is giving you a solution)
  • Give me a specific example?
#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.