Virtually merging two tiddlers? Tiddler stacks and form of monkey patch

Developers
#1

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.
[Proposal] Updating field handling functionality in TiddlyWiki
#2

Ultimatly this idea of tiddler stacks is to pull the first field value from a given field in a “stack” of tiddlers. In other words given a set of tiddler titles get the first value with a given fieldname. In effect this list of titles is the “tiddler stack”, then we retrive the first value stored for a given fieldname in that list of titles.

  • No need to test a non-existant tiddler, so the stack need only include existing tiddlers ie: has[title]
#3

I think this is an interesting idea - I think you could do it out-of-core with the technique you described.

I know that I’ve wanted something like this in the core in the past for things like "I want to remove something from tags" or "I want to change the order of list" without creating a full copy of the underlying shadow tiddler, but I’ve found myself questioning the value of the feature in comparison to the additional complexity it would bring!

1 Like
#4

I can see how such a mechanisium may help us avoid modifying a shadow tiddler by providing an alternate version of the tags field that is in a cascade. I am not sure if we can avoid creating a tiddler to do this with.

My own objective would be to make this as simple as possible.

But your comment made me realise that clearing a field, ie gving it no value, overiding to to blank has its own challenges when using a cascade.

#5

That looks like how bags works in MWS, have you try that? Bags can shadow each other like cascade.

#6

although I am trying to do this on single file wikis in a sense.

#7

I asked a very similar question in #6175, eventually phrased like this:

We have a shadowing mechanism, allowing us to use our tiddler in place of another, even though that other one still exists and will be resurrected the minute our own is deleted. Could we do the same thing at the field level?

Jeremy explained that while this is an interesting idea, for some very good reasons, it could not possibly make it to the core.

I noted the following and then dropped the idea. One day I may still come back to it:

Maybe there are enough differences in your current idea and that one that we could achieve it, but I’m doubtful, not without the sort of replacements I mentioned for some core constructs.