As recently triggered here Macros listing fields with spaces in their names - #11 by TW_Tones I would like to propose “Updating field handling functionality in TiddlyWiki”.
- I have researched this at length over the years and have plenty of ideas and methods to share but raise this topic to include those with the appropriate expertise.
- If implemented correctly this will add functionality but not demand any changes unless a user wants to leverage this functionality.
- The following is a full and systematicaly developed “requirements document” so please forgive me for its verbosity.
To keep this simple I will list the features I would like to see and simply assume the “use case” is obvious to readers rather than justify the requirements. I happy to address that later or elsewhere if contested;
- Initialy introduce as a plugin then propose migration to the core once mature.
Features
Develop a system that allows “Field Tiddlers” missing or otherwise. Similar to tag tiddlers.
- Provision the following filter operators. If this is crowding “is” and “all” perhaps allfields and isfield?
-
[all[fields]alternativly use “fieldnames” -
[is[field]alternativly use “fieldname” - I expect we can already create custom filter operators such as all.fields[] and is.field[] but I would like to see this prepared for inclusion in the core one day.
- Another approach may be to expand the functionality of the current
fields[]operator
-
- Make indexed filter operators for fieldnames (if not already) see Performance
- Also use in the “fields Operator”
- Provision list/filters of registered fieldnames for include or exclude as needed, see TiddlerFields perhaps intergrate with an operator and indexing eg;
- standard system fields
- core fieldnames
- System/Plugin and user fieldnames
- Find a way to systematicaly non-distructivly add/remove from such lists.
- We may wish to extend the way we currently determin if a field is a User or System field including a system field prefix (less vferbose than $:/… or $:/plugin/pluginname/…) generic and custom (eg pluginname_fieldname)
- I am raising this now because I belive we should implement it before the next major release if possible.
Cascade features
- Introduce a “Field View” Cascade that can use a view template for that field, within or referenced from a “fieldtiddler” if it exists.
- Include in the existing “Field Editor” cascade, that can use an edit template for that field, within or referenced from a “field tiddler” if it exists.
- If we have field tiddlers it makes sense to consolodate various field handling features in a field tiddler. It would then be possible to share such field tiddlers to share the definition with others. It would also show when someone attempted to import a new field definition if one already existed (similar behaviour exists for tags already).
- Introduce a widget or two that allows the above edit or view code to use used on a nominated fieldname via the define cascade (or alternative).
Notes on naming
There are variouse opinions as to wether it is permissible to name fields with plane english words or enforce prefixes. This should remain posible and at the behest of developers and designers not enforced by the core.
- I have made a number of solutions using plain english words for field names without issues and would not be happy if a fieldname prefix was enforced. That is not the case with existing system fieldnames so this should be maintained.
Subsequent features
Once the above becomes mature we could include “field tiddlers/definitions” in the core or as installable packages (plugins) sets of field definitions and fieldname cascades that provide view and edit code for named fields both that come in the core and with plugins or as the result of a design/edition.
- A designer may be able to pull all defined fields in one wiki to use in another new wiki, there by quickly reusing substantial “prior art”.
- Existing field edit tools like color and additional ones for date, tag and title pickers, select and select multiple etc… could then be migrated to the field handling mechanisium.
- Just as tiddlers can be placed in both view and edit modes a future development should introduce a similar mechanisium for fields. Again I have done substantial design work already, and will share / propose in good time. The simplest form of view/edit is in the above proposal, however there should also be mechanisiums to allow modes such as field edit from within forms used in view mode. Including an update mode where the field is in view but a mechanisium to edit inline made available.
if you would like us to proceed but not exactly As presented please 
if you agree with what is proposed as a whole. Please reply if you have specific concerns or are in a position to contribute.