How do you keep track of all the user-fields that can end up in your wiki? Especially if you have several plugins that introduce their own fields, it can be tricky to remember what field is used where.
The bibtext plugin has a namespace in the fieldname: bibtext-year etc. But this is not always the case.
The ‘official’ fields that come default with the core have a description in the fields-tab in the control panel. Can pluginmakers easily add these to their fields as well?
Any experiences?
Yes, but only for 1 language. … And the plugin authors would have to do so. So the best way will be to reach out to them and suggest, that they should add them
Not sure what the problem is? In edit mode you see all the fields in the dropdown that appears when click to create a new custom field. And if you want a “manual” listing of the fields you can just create a simple list with filter [all[tiddlers+shadows]fields[]]
How would you want this info presented?
The list of all the default fields is defined by this tiddler :
$:/core/ui/ControlPanel/TiddlerFields
And it use this snippet to render the table :
$:/snippets/allfields
Any new field will be listed in the table. To add a description to a field, create a tiddler with a title formatted like this :
$:/language/Docs/Fields/$title$
@Odin this is a good question. Although as @pmario points out the use of fields is often chosen by the plugin developer and more generally any designer or even end users who create a field. We should encourage the documentation of field’s used especially when a solution is published or shared.
Not withstanding the above, you may be surprised to learn that there are heaps of ways to extract information about fields, their use and their scope. This continues one of tiddlywikis key features of self documentation where almost all plugins, macros and templates are user readable. I think we could make available more tools to help with field management.
What do I mean by scope? Whilst you or anyone else can define a field to have a somewhat global meaning ,for example I often use the object-type field and the view templating process may make use of it, many fields gain their meaning from their context. In fact with object-type what needs to be unique is the fieldname/value pair which makes it even less likely to clash with other solutions using the object-type field. If a designer identifies there is a possibility of a clash they can just use additional field naming standards such as a prefix eg; PSaT-object-types where PSaT is my “brand”.
For non-global types of fields in many ways you can reuse the fieldname as needed because how that field is handled depends on the context, or even an individual tiddler. By using the object-type I set a context for a tiddler so when I write something to handle, let us say, the “tooltip” field and use it as a tooltip, I do so only for items with an object-type field, or an object-type=note thus tooltip is still available for reuse elsewhere. By its very name tooltip implies a tooltip as it relates to the tiddler it is encode in, so it retains a very local scope and can be reused without clashing, and the tooltip field used in one solution may do the same thing in another solution without modification.
In the worst case scenario of a serious clash of fieldnames, which is quite unlikely, typically a small modification and a conversion button (eg; create and copy field content to a new field) can set things right.
All of the above shows how “Tracking fields” is not such a big issue as one may first think but it also illustrates how difficult it would be to infer the meaning of given fieldnames when they can be used in so many ways and contexts. No one record of a fields use may be enough since it may have many.
So in response I think your original request may be satisfied by;
Yea, … It should become “best practice” for “content creators” that create new fields and intend to rely on them, that they document them with the plugins. …
Very interesting thread!
I agree that documentation of any added fields helps.
In the back of my mind is also shared naming – meaning where do plugin-developers discuss and co-conform field naming?
Just a comment
TT
“On the quite” …
“It depends” … If there is some “early” user feedback it’s probably discussed every plugin iteration. …
To be honest. At the moment I only know some field names that my plugins create. Some plugins use a wl- or wl prefix. wl … for wikilabs
Some examples without prefixes.
There is one: subtitle, which I use instead of “caption” in probably several plugins … “subtitle” is similar to “caption” but longer text.
aliases and subtitle is used by my uni-link plugin. … But I know there are other plugins that use aliases too. The usage may not be compatible. Since those plugins serve the same purpose with at different “philosophy”, only 1 of them should be installed anyway.
The parent field is used by my tocP-plugin. … Saq’s streams-plugin uses the same name on purpose, because I did suggest it. It can probably be used by a future version of the tocP plugin, which would make sense.
Some plugins use filter and list in the exact same way as tw-com does it. list is documented by the core. filter is not but used by the $AdvancedSearch function. So imo it’s a “de-facto standard”
When making solutions I may publish broadly, one day, I can’t bring myself to use heavily prefixed tiddler, tag or fieldnames. I actually like making solutions which are simple to read and meaningful.
However I have started to establish some personal standards and as yet I have not had a clash. As illustrated previously one of the easiest ways is to contextualise, so using object-type (because type is already used) to classify tiddlers I can always rule in/out the meaning of a fieldname for all with or without object-type or object-type+condition I am using.
I think with a little caution any plugin or macro suit can used almost any non standard field with little or no clash, if a clash occurs it is often a simple matter of changing one or more of the solution’s, and if not I tend not to use that solution. It may be adding a subfilter to existing macros but as long as a solution provides configuration options most clashes can be avoided.
Mario, This highlights the cases where the fields used may cause problems and clearly this is where we must try and ensure documentation. Perhaps we ask the following questions;
However your reply made me realise that the devil is in the detail.
I think we can find some suitable design methods to reduce the potential for interference.
Perhaps also a feature rich plugin inspector could provide insight in which fields are used where.
Imagine a plugin includes a tiddler that lists the fieldnames it makes use of and provides a link to the plugin. A field registrations tiddler, perhaps also a tag registration tiddler etc… Perhaps feratures to add to Gatha @Mohammad ?
Is there a way to write a filter expression that only returns fields that I have added to the wiki?
It looks like $:/core/ui/EditTemplate/fields does this to generate the “user fields” list in the “Add a new field” dropdown:
[!is[shadow]!is[system]fields[]search:title<newFieldName>sort[]] -created -creator -draft.of -draft.title -modified -modifier -tags -text -title -type
Which I can adapt, it just seems a tad brittle. I tried to use
[all[shadows]removeprefix[$:/language/Docs/Fields/]]
But that doesn’t seem to work with the macro I borrowed from elsewhere:
\define renderfield(title)
<dl><dt><$link to='$:/language/Docs/Fields/$title$'><$text text=<<__title__>>/></$link></dt><dd>//{{$:/language/Docs/Fields/$title$}}//</dd></dl>
\end
If I could get this to work and flip it to saying non-shadows, then this might be cleaner, although this assumes that I have added an entry to the language directory for any new fields I create. I think I’ll use the first filter and add a few more exclusions. Just wondering if I am missing anything.
Perhaps this would be best a new thread; with a link to it from /to here. However my answer which involves lists of fields in macros to identify them is arguably needed in Best Practices.
@JenniferS perhaps the most practical way is to build a global macro naming each standard or system tiddlers;
The tiddlers hidden from the field editor have a visibility tiddler set to hide see advance search filter [all[shadows+tiddlers]prefix[$:/config/EditTemplateFields/Visibility/]]
\define core-fields() title tags text creator created modified modifier type draft.title draft.of revision bag
Then when trying to determine additional fields, those you added, you can do this; rule out core fieldnames
{{{ [all[current]fields[]] -[subfilter<core-fields>] }}}
alternatively you could make a global macro that lists your fields and do this; rule in your fields
{{{ [all[current]fields[]] +[subfilter<my-fields>] }}}
using the above filters in a list widget as needed.
Also with field handling have a closer look at the has operator because it allows you to test for a specific field empty or not.
Is there a method to see all the field values per field?
I would like to make a dropdown option for field values, but I’m not sure how to search by field value atm.
In sort [all[current]get[fieldname]] for current tiddler, [all[current]each[fieldname]get[fieldname]] for one of each existing values (if relevant) from all tiddlers.
the search operator also says [search:<field list>:<flag list>[<operand>]] eg [search:title,caption:literal,casesensitive[The first]]
The easiest selection drop down in the select widget; eg select from existing values.
<$select field=fieldname>
<$list filter='[all[shadows+tiddlers]each[fieldname]get[fieldname]] [[value1]] [[value2]] +[sort[]]'>
<option value=<<currentTiddler>>><$view field='title'/></option>
</$list>
<option value="" >(clear)</option>
</$select>
+[sort[]] at the end of the filter[[value1]] [[value2]] before/after the sort for always available optionsPerhaps explain what you are after a little more ands/or start a new thread.