Folks,
I am wondering if there is a way we can make a composite tiddler such that one tiddler may have a superior or subordinate tiddler (3 total for this discussion). Then by some mechanisium we can reference this “tiddler stack” and the values returned for named fields, will be determined by a cascade of the fields in the stack. Depending on the order one tiddler will win the value by being higher on the stack. If a field with a value is not in two of the tiddlers it will still look as if it is in the virtual or composite tiddler.
- This would allow us to point to a detailed behaviour but override that value by setting it higher up in the stack.
To help with naming perhaps rather than currentTiddler we refer to currentStack and the cascade mechanisium somehow returns the cascaded value. I could see a version of the field, has and get operators that operates instead on a stack of tiddlers. stack.field, stack.has, stack.get and possibly a variant for list fields like tags.
The idea is a generic mechanisum for stacking tiddlers and having a form of cascade for the fieldnames in that “stack”. It may be used in interesting ways, but for now I want it for the following;
My use case
To help simplify the handling of field definitions and field-types in this discussion [Proposal] Updating field handling functionality in TiddlyWiki I realised that often a field-definition may quickly use a field-type for example I may have a field background-color and it has the type color. As may other fields.
- To create a new field you give it an existing field-type and it inherits all its fields and values. Including a field containing a values-filter.
- Now perhaps you want to limit the color palet for background colors you may just overide the value-filter in the field-definition tiddler, so now the field has a bespoke values-filter.
Now when programaticaly responding to a given field definition we just query the field definition and field-type cascade to get the relavant values.
Of note:
There will always be an equal or smaller number of field-type tiddlers than field-definition tiddlers. this is a more efficent design approach and it minimises the size of code to handle field definitions and avoides redundancy when not needed.
Futures
This may prove to be away for people to introduce cascades without the complexity of those implemented in the core template cascades.
- It may provide a way to introduces changes to core tiddlers without altering the core tiddler, just have it as part of the stack. A form of monkey patch, where the other tiddlers in the stack are made visible when viewing the core tiddler.
- This method may permit more than one overide of a core tiddler to be applied by more than one plugin.