Separating user defined fields from, well, all the others

#21

(I’m adding this as a separate post, because it’s not actually quite what ChrisH’s particular case needs. It’s just a nice tweak I came up with, so I thought I’d share.)

This filter is amazingly creative, and solves a minor problem I’ve had for a while! But I found it to have one small flaw: it does not exclude fields used in plugins. So here’s a way to get the results without these plugin fields included:

[subfilter{$:/config/EditMode/fieldname-filter!!first-search-filter}] -[all[shadows]removeprefix[$:/language/Docs/Fields/]]

As noted in my post above, the $:/config/EditMode/fieldname-filter tiddler’s “first-search-filter” field contains the list of all user-created fields, which is used for the add-a-field dropdown list’s “User fields” section. By using this existing filter, we can take advantage of the core’s method which excludes plugins’ fields from the “User fields” section.

  • If we solely use the language method to filter, it would include any plugin field or core field that doesn’t have a language entry – for example, in my wiki, the “demo” field that the Relink plugin uses was included, as well as the “status” field that the core $:/Import tiddler uses.

By then adding your language-based method to exclude system fields, that also excludes originally-system fields like caption or code-body which might regularly be added by users.

Thus, the output of the above tweaked filter should be EXCLUSIVELY user-created fields – well, as long as nobody’s added their own language entry for them!

#22

That’s a very nice addition, and I think there are times I’d want either one.

Often I don’t want to care about what’s in plugins. Mostly I would use this for when I want a list those fields I use in a particular tiddler that are not part of Tiddlywiki’s core. That Relink uses demo, AutoComplete uses rows and PlantUML uses documentation, would not stop me from using them for my own fields. But I’d probably always avoid type, or modified.

Other times, it’s possible that I’d want to scan the whole wiki, plugins included.

The big concern of course is that somebody adds these $:/language/Docs/Fields/* tiddlers for other fields, and ones we care about disappear from the list. I guess they shouldn’t. Jeremy has recently made it clear that he thinks of the $:/language namespace as reserved for the core. But it’s a concern. For my own uses, it would not be hard to whitelist back in a value that is otherwise restricted by these techniques, but it’s easy enough to imagine places where that is not possible.

Very good point. And in fact, I’m going to edit my post to include that.

#23

Hi Scott,

Well, I don’t know what to say other than thank you very much for going to all the trouble and effort of writing such a comprehensive post. It’s very generous of you and I’m very grateful to you for it. The post is really helpful to me and I’ll try it all out tomorrow. It’ll also force me to try to get my head around working with HTML code, a subject that I know even less about than TiddlyWiki’s inner workings.

Best regards and thanks again,

Chris

1 Like
#24

Hello Greyed,

It’s nice to make your aquaintance too. And thank you very much for this additional material! My reply to Scott just now clearly applies here with equal weight. It’s seems clear that the TW community is a friendly and generous crowd. I’m quite overwhelmed by everyone’s kindness, though you are all stacking me up a big study day tomorrow.

Best regards, Chris

#25

I have explored fields deeply but will always use the fieldnames I want without prefix or suffix except if I want to groups the fields.

A smart approach is to use a field such as object-type (because type is in use) and use this when designing tiddlers with custom fields and thus you can list all fieldnames that belong to that object-type. You can call this self documenting.

  • There is rarely if ever a clash of fieldtypes if your solution has this other layer of naming, the object-type, just dont list or consider a custom field unless its in a known object-type.
  • Your solution will not have any problems due to others using the same fieldname else where. Other solutions rarly clash, although I avoid the system fields.
  • When using current tiddler you need only query the fields on the current tiddler. Include empty fields.

I will see if I can find my own field filters or lists I use in a function so I can filter fieldnames dynamicaly.

[Edit] Use relink plugin for fields as well

#26

Hi Anthony,

Thanks for your advice, I appreciate it. But can you clarify for me one of the points that you made? It’s this phrase from your second paragraph.

I’m not sure how to interpret that. Do you mean that one should use the “object-type” field, for example"? I don’t think so because I can’t find such a field but thought I’d ask, just to be sure. Or are you proposing “object-type” as a generic naming convention for user defined fields. So that the “object” part is a field specific name, whereas the “type” part names a (possible) group of related fields?

I have used something like that format for a few of my own user defined fields, though my constructions take the form “type-object” not “object-type” but it serves the same function. For example: “game-date” to reference an arbitrary date in the game; “location-aft” and “location-fore” to reference locations on the game map that are immediately behind and just ahead of some character or group. You see what I mean.

I didn’t do that as a rule, however, because I preferred to use single nouns or verbs as names wherever possible, as you would, it seems.

Best regards, Chris

#27

Imagine a wiki that tracks purchases for your online store. You might have tiddlers categories of Customer, Supplier, Item, LineItem, and Order. My own preference would be to add tags of Customer, Supplier, etc. to the appropriate tiddler. But some people like to keep their tag space very tidy. So instead of a tag, you could use a dedicated field, say, object-type:

title: Acme Manufacturing
tags: (whatever)
object-type: Supplier
...

title: Wile E Coyote
tags: (whatever)
object-type: Customer
...

While we might prefer to use type, that one is used by the core, and is quite important to the functioning of TW. We couldn’t well reuse it for something else.

#28

Thanks Scott. That’s clear now. Regards, Chris

#29

I am suggesting the use of a custom field such as creating a field “object-type” so each tiddler you create can be assigned an object-type eg contact, character, business, document. Then when you use additional fields they are added to the tiddlers with a given object-type.

  • As you qualify a fieldname (mobile-phone-number) as belonging to an object-type eg “contact” the same fieldname can be used in another object-type with a different meaning.

The reason I chose object-type is because I wanted to use type but it is in use, the word object implies a tiddler represents an object, a logical object in database terms.

The thing is when you add this logical grouping of object-type you write your lists and code to first filter on object-type and it will never accidently use the same fieldname from other tiddlers or plugins, and you are able to use what ever fieldnames you want.

#30

Hi Anthony,

Thank you for taking the time to offer this clarification. I’m grateful. I’ll need to mull that over for a while to work out the ramifications but here’s what I understand you to be saying at first glance.

“object-type” is your suggestion for the actual name of a user-defined field that I could add to every non-core tiddler in the wiki, together with a value taken from a set the members of which specify particular "type"s (eg message, character, event, decision) of “object” (ie non-core, non-plugin tiddlers).

The field is then used early in any filter run to select only those tiddlers that either have that field or, more selectively, match a particular “object-type” value of that field.

The aim of this early filter is to ensure that any field name that is used later in the filter run that duplicates the name of a system field could only be attached to a non-core, non-plugin tiddler and so must be: (a) the user defined version of the field: and (b) only be carrying a user defined value for that version of the field or no value.

OK, :thinking: … I’m pretty sure I’ve got that now :crossed_fingers: and I’m even more sure that it would work as I already achieve something similar with tags, having names such as those in the example that I gave in parentheses, earlier.

The question that remains is whether it’s the right way to go? I have a nagging feeling that we’ve come adrift from the original problem, though with the definite advantage of having created some really useful TW learning opportunities for me.

My original problem was, how do I generate a reliable list of the user defined fields to be found in the wiki and only those fields. The main reason behind that was to use the list in a table which would: (a) list all the user defined fields (duh); and (b) provide a description and intended function for each. I think that question is now well answered. My thanks (in case I forget) to ansolutely everyone who’s chipped in.

For what it’s worth, I think that the second best solution for me is to rename the duplicated field or fields as that seems like the better practice in any case. I can then work on the most efficient way to get that list from a filter, from among the many ways that have been suggested.

So I’ll get on with that while also thinking about how I get to the “best” (OK, “better”) solution to my original problem, apart from deduplicating the names. (“Deduplicating”? Did I actually write that? Is deduplicating actually a real word or did I just make it up?)

So that is, how can I add my description and intended function to directly each user defined field so that the information populates the table that Scott created in his earlier post? See post #13 May 20, 2:28 AM.

I think there’s more than enough guidance available to me from Scott’s post to allow me to tease that out, so no one need feel obliged to write a “how to” for me though I’m grateful for the thoughts that were probably already forming and more than happy to get one if that’s what anyone actually wants to do.

Right, I’d better stop now. Things to do, places to go, people to see … 'Bye for now and thanks again, Chris

#31

In reality perhaps you want to do this for the tiddlers you introduce not all tiddlers with custom fields so as an example you may use a filer to find all fields in all your object-types. The advantage being if you add a field to any tiddler with an object-type it will then appear in your list.

  • Not withstanding this you can use tiddlywiki.com, or an empty.html and find all the standard fieldnames, put these in a list, within a function and use this in filters to exclude the “standard fields” all else are custom fields, or from additional plugins or tiddlers. Exclude fields not defined in your object-type tiddlers and you can see.

Real word, desperatly importiant in IT, especialy in the old days of batch programing, but sneeks in in many places :nerd_face:

#32

Thanks Anthony,

That’s a good point but in this case custom fields (i.e. user-defined fields) are only present on tiddlers that I’ve created. I haven’t added any fields to tiddlers that are part of the core or of any plugins. In essence I just want to be able to list those fields that I’ve created for the purpose of running the game together, ideally, with their descriptions just as a reminder of what they are and what I’m using them for.

Thanks. And consulting the online Oxford English Dictionary, I’ve been very surprised to discover how far back it goes.

The earliest known use of the noun deduplication is in the 1830s.

OED’s earliest evidence for deduplication is from 1835, in the writing of John Lindley, botanist and horticulturist.

deduplication is a borrowing from French. Etymons: French déduplication.

Incroyable, non?

Anyway, thanks again and best regards, Chris

#33

Incroyable, Oui.

I think there is more to be said on this subject so when I get the chance I may add a little more here. For example

  • Documenting the difference between fieldnames as they appear on the add field dropdown, which shows shows user and system tags seperatly.
  • Including a “registry” in the form of lists, that group logical relationships between sets of fieldnames.
  • documenting how to hide fields from the field editor as modified and created already are
  • Identify is there are there places we should request some additional hackability