Improve Standard and Core Field Documentation

#1

I would love to think there is a rule like this, but as is often the case it depends on your definition. See tiddlywiki.com define these here already. https://tiddlywiki.com/#TiddlerFields

By standard fields I am talking about fieldnames already used for a purpose in a tiddler, examples may include description, caption, color, Icon. Even if you make use of these fields for you own purpose the core will continue to regard them. These fields have meaningfull definitions and its Great for the user/designer to be aware of these and use them in the same way.

  • The system also maintains a few of them such as modified/created fields and there is value not interfering with them as they are valuable as a source of truth.
  • There is value knowing which fields

The simple need is when you use [all[current]fields[]] and more globally [fields[]] you will get many fields listed. I want to be able to detect other fields on a tiddler and only handle them. We can call these fields custom.fields and they tend to arrive from plugins or user data entry.

  • Going forward if I build a system for field handling field- prefix and field-type- prefix I may want to add these to a system fields list, to remove them from the custom.fields list. In part because I have the templates to handle these fields

The problem is they contain “standard.fields” and other “core.fields” which access a manual list. It is these manual lists I believe should be in the core or at least available in a core plugin perhaps?

  • perhaps as tv-standard.fields etc…
  • Its just like registering or documenting core and system fields, we will either not reuse or if we do so we do it with the knowledge, so too does the core.
1 Like
Using the remove operator with titles from a function
#2

The TiddlerFields tiddler currently contains manually created tables.

I would be OK, if those 2 tables would be created dynamically, so they can represent the real current state of the wiki.

For that to happen, it would be needed, that we maintain 2 lists that you propose here. The names may be subject for discussion but I think tv-???-list or something similar would be worth a try.

The advantage of such lists would be, that they also would be translatable.

I would support endeavours in that direction.

To make those definitions usable in different wikis, it would need to be a plugin. — For plugins we do not have translations at the moment. But there is a pending PR, which seems to be stalled at the moment.

@linonetwo … What happened to translatable plugins?

1 Like
#3

If I am not wrong there is no hard rule to obtain these dynamically, that we cant already do, I am interested in it being a curated list, so it captures fields not used at tiddlywiki.com in a similar way many system tags are documented but do not exist in the wiki, nor are in use.

For example;

\define all-system-tags() 
$:/tags/TextEditor/Snippet
$:/tags/ClassFilters/PageTemplate
$:/tags/ClassFilters/TiddlerTemplate
$:/tags/Global
$:/tags/Global/View
$:/tags/Global/View/Body
$:/tags/AboveStory
$:/tags/AdvancedSearch
$:/tags/AdvancedSearch/FilterButton
$:/tags/Alert
$:/tags/BelowStory
$:/tags/ControlPanel
$:/tags/ControlPanel/Advanced
$:/tags/ControlPanel/Appearance
$:/tags/ControlPanel/Info
$:/tags/ControlPanel/Plugins
$:/tags/ControlPanel/Saving
$:/tags/ControlPanel/Settings
$:/tags/ControlPanel/Toolbars
$:/tags/EditorToolbar
$:/tags/EditorTools
$:/tags/EditPreview
$:/tags/EditTemplate
$:/tags/EditToolbar
$:/tags/Exporter
$:/tags/Filter
$:/tags/Image
$:/tags/ImportPreview
$:/tags/KeyboardShortcut
$:/tags/Layout
$:/tags/Macro
$:/tags/Macro/View
$:/tags/Macro/View/Body
$:/tags/Manager/ItemMain
$:/tags/Manager/ItemSidebar
$:/tags/MoreSideBar
$:/tags/MoreSideBar/Plugins
$:/tags/PageControls
$:/tags/PageTemplate
$:/tags/Palette
$:/tags/PluginLibrary
$:/tags/RawMarkup
$:/tags/RawMarkupWikified
$:/tags/RawMarkupWikified/BottomBody
$:/tags/RawMarkupWikified/TopBody
$:/tags/RawMarkupWikified/TopHead
$:/tags/RawStaticContent
$:/tags/RemoteAssetInfo
$:/tags/SearchResults
$:/tags/ServerConnection
$:/tags/SideBar
$:/tags/SideBarSegment
$:/tags/StartupAction
$:/tags/StartupAction/Browser
$:/tags/StartupAction/Node
$:/tags/Stylesheet
$:/tags/TagDropdown
$:/tags/Texteditor/Snippet
$:/tags/TiddlerInfo
$:/tags/TiddlerInfo/Advanced
$:/tags/TiddlerInfoSegment
$:/tags/ToolbarButtonStyle
$:/tags/TopLeftBar
$:/tags/TopRightBar
$:/tags/ViewTemplate
$:/tags/ViewTemplate/Subtitle
$:/tags/ViewToolbar
\end

I need to know if I am missing any?

#4

And perhaps more completely, by

Which yields these values:
_canonical_uri creator list-after source
_is_skinny current-tiddler list-before stability
author dependents modified subtitle
bag description modifier tags
caption draft.of module-type text
class draft.title name throttle.refresh
code-body footer parent-plugin title
color hide-body plugin-priority toc-link
component icon plugin-type type
core-version library released version
created list revision
1 Like
#5

Need some work, I have initiated the discussion:

Suggestion for all Plugin developers about field name: Let’s use Ontology to maintain Interoperability

And I made

See its doc site.

And I have some issue on main repo like

But as TBL said, you can safely use different fields for same thing, just transform them when you want to use them (Linked Data is Like a Bag of Chips - Design Issues - Tim Berners-Lee), like:

And tiddlywiki user group is too small to make use of these ontology, its user and dev group is not bigger than close sourced Obsidian.md.

So I ceise to spend time on these projects.