Do you mean if, for instance, I installed multiple plugins that all included a different override for $:/core/ui/PageTemplate — that is, they all included a shadow tiddler $:/override/$:/core/ui/PageTemplate?
Honestly, I don’t have a good answer. I suppose I would expect the last version to win? This wouldn’t be any different from the current system, though (where, barring a non-shadow version, the last $:/core/ui/PageTemplate would be used), so I don’t think it’s particularly a downgrade.
How would your flags approach solve this issue? I apologize if you’ve explained this previously; it’s not coming readily to mind.
I haven’t thought it through very carefully, as without this extension mechanism, it makes no real sense. But I needed a break from all the politics stuff I was working on last night. (I’m co-chair of my local Democratic Town Committee, and municipal elections are fast-approaching!) Creating that silly little states list was exactly the right 20-minute project. I don’t know that I would actually use states that way, but it might be a great way to deal with the lists of elements and compounds for my periodic table wiki. I’ll have to consider it more.
Yes, but I’ve spent no time imagining a design for this. Thanks for the start. It sounds like an excellent system. But I am worried about anything that steepens the learning curve for using TW. So I’m wondering if there is an alternative which makes a single up-front choice about whether this edit session is for a regular tiddler update, a shadow tiddler clone update, or an override update, and then everything happens on a single tiddler.
One more major caveat, also about deleting fields. Does an override tiddler simply set the value of a field to blank in order to override it? If so, are there places where this will cause problems? Because these two are distinguishable: has[xyz] and has:field[xyz]. What if we want our override to set the field value to the empty string? How do we distinguish between that and removing the field?
$:/override/Tiddler A has field foo: — that is, an empty field. (If the field’s not present, no override occurs.)
In this case (assuming that has and get and other similar operators look for override fields first) I’d expect [[Tiddler A]has[foo]] and [[Tiddler A]get[foo]] to return nothing, and [[Tiddler A]has:field[foo]] to return “Tiddler A”. This would make it functionally impossible to get [[Tiddler A]has:field[foo]] --> null if an override exists. Is that the issue?
It strikes me as a fringe issue, but worth pointing out. And I’m afraid I don’t have a good solution in mind.
In writing this, it occurs to me that we might also want additional suffixes for has and get — perhaps :original and :override to look only at the corresponding original/override tiddlers, rather than following the typical override → original priority list. So there would certainly be added complexity…
I’m feeling ever less optimistic about the feasibility of this approach. Still, thank you for the reality check.
I think it’s likely a minor issue, but I’d want to know that the core, official plugins, and other popular plugins and editions don’t actually use that distinction. If they don’t, then it could be a documentation footnote. If they do, we have more issues.
Sorry.
I do still have hope, although it too is somewhat diminished.
Part of the trouble is that what I’d really want is one large step further than this: the equivalent of nesting doll tiddlers, where an outer tiddler may have the field we want, but if not we check with the one inside it, and then the one inside that one, until we find it or run out of dolls. Jeremy explained in that thread why, although a possibly very useful approach, it cannot be added to the core. But I may one day try to get a version of it in userland.
it does not solve the problem you pose, only demonstrates a no touch method. It needs further design.
I think I fixed the solar panels.
Today I pack for a house sit that starts tomorrow.
There may be some room to use the existing shadow tiddlers system, the last plugin wins but I wonder if we could provide more visibility and control of this process for targeted tiddlers. it is actually quite easy to move a tiddler into and out of a utility plugin. if we can read all versions of a shadow then we can see all variations and generate a synthetic tiddler.
I just reviewed this issue, and one idea, which may be equivalent for you is redirection via transclusion.
If you get a field value through transclusion and that field has a transclusion in it, then it will keep transcluding multiple levels deep until if returns a value.
{{!!fieldname}} when fieldname contains {{parentTiddler!!fieldname}}
When the parentTiddlers “fieldname” contains {{otherTiddler!!fieldname}}
When the parent tiddlers “fieldname” contains a value it will return "a value’.
Of course this could be turned into a single filter cascade that looks at multiple locations until a value is returned, and one could make the tiddler names tested as programaticaly generated.
Moving it into a function even better get.fieldname[]
I would find this too heavyweight. It would mean that child tiddlers had to know and copy all the fields of their parents to add the transclusions necessary to follow through the chains. And if the parent changed, then all children would need updated.
This, on the other hand, is what I think would potentially work. It wouldn’t be just a single function. We would need extensions to the get operator, the $view widget, and many other things. The question is whether there is a relatively small core of these which the other could themselves call. I haven’t done any of that analysis, but I do worry that this would be quite a large undertaking. In that thread, IIRC, Jeremy mentioned some place where he’d done something like this Object inheritance, but I never looked deeply at it. When and if I do, I will be examining that closely.
Wether its light or heavy is realy dependant on meta issues. The children may not need updating.
However if such a field value cascade is going to work, there needs to be an identified logical pattern where to look. ie what ties the one or more tiddlers together.
Have you an idea for the cascade pattern in your mind?
I recently used a transclusion to invoke a template to replace headings here Table of Contents from Headers - #9 by TW_Tones lets say that we move the cascade to a tiddler such that a field value may contain {{fieldname||cascader}} and within the tiddler cascader was the logic to source the value from an established cascade, for example from the same fieldname in $:/ghost/currentTiddler then $:/default/currentTiddler and if nothing a default value.
Further work may allow the default to be provided in the transclusion {{fieldname||cascader|default}}
An importiant point is that transclusions can be nested, and a reference to transclude a field will work through the series of transclusions like other cascades.
keep in mind the currentTiddler will be the title in the transclusion, eg Fieldname, you can use storyTiddler to find the visible tiddler.
In this proposal a field is just a field with a value, unless that value is a transclusion. all be it accessed via transclusion or reference (not with a get in a filter). So in the “end tiddler” we can change the value that suggests you need to get it from elsewhere, elsewhere is resolved by the transclusion of a utility tiddler. eg the above cascader tiddler.
Think of this as giving the field a special value, one that can be sourced from a cascade.
I can give an example if you can answer;
Have you an idea for the cascade pattern in your mind?
[Post script]
The other approach is to reference the field value as a filter allowing the field value to contain the cascade filter itself.
Just as we have the ability to provide a custom field editor, we could do this to view or retrieve the field as well. Where that field contains a filter or transclusion (function or procedure) to resolve the value.
Yes, I discussed it in that thread we’ve mentioned. The idea is simply that a tiddler may have a field, let’s say, _parent_tiddler that contains the title of another tiddler.
A new get' operator begins to work like the current get, but if the target tiddler (Tiddler Z) does not have the field we’re seeking, then it checks if Tiddler Z has _parent_tiddler. If it does, and let’s say it has value “Tiddler Y”, then we check if this tiddler has that field. If it does, we just return that. If it doesn’t, we check if Tiddler Y has _parent_tiddler, rinse and repeat. Eventually we’ll hit a tiddler that doesn’t have a _parent_tiddler… maybe all the way down to “Tiddler A”. Only if that final one also does not have the field do we return an empty value.
Setting a field wouldn’t change. We would set on Tiddler Z. But we do have access to the other tiddlers, and if we updated the value in, say, Tiddler M, the new value would show up in Tiddler N, unless it was overridden, and then in Tiddler O, again unless it was overridden… and eventually in Tiddler Z. In practice, I would not expect very deep hierarchies, but they would be available if necessary.
This would not be only the get operator. It would also involve the $view widget, and probably many other places.
The whole point is to answer this question from that thread:
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?
So as a test perhaps we could use the parent field using TOCP of marios?
So a tiddler has zero or one parent and if no value is returned (or the field does not exist) we look in the parent… then if not found use a default.
Why do you mention the view widget? My personal feeling is widgets are where things go to be displayed. I would not use it as a result.
Another alternative is the lookup operator.
I am doing a few tests off line and it all looks promising, down various routes.
I have often used a macro to retrieve a field value because that macro can be arbitarily complex, if it cant return the value from the actual field it can go and find it elsewhere. Including climbing a tree. Although now days I would preferentialy use a function, even custom operator, it returns the first value, as text and nowikification required.
title My Iron Research
_parent_tiddler: Element/Iron
boiling-point: 3122
Iron is an amazing element, made famous of course by the suit of
[[Marvel Comic|https://en.wikipedia.org/wiki/Iron_Man]]'s ''Iron Man''.
It has an atomic number of <$view' field="atomic-number"/> and
an atomic mass of <$view' field="atomic-mass"/> My lab partner
and I calculated its boiling point as <$view' field="boiling-point"/>
But you want to know the crazy thing? Iron Man's suit isn't actually
made of Iron! I know, false advertising, right?
...
When we view that latter tiddler, we want the atomic number and mass to shine through from the parent tiddler, but we want the text and boiling point from the child.
The following will do that. The $view widget cant display anything but something found in a tiddler field (by default text) so it is of no value when wanting to view the result of a function, transclusion or procedure.
I rarely use the view widget now, and the format operator helps out as well.
Instead you would use one of the following;
With your required fieldnames.
This would be if I modify get.fieldcascade to follow the parent
we could add a parameter that rather than seek the first value, it can seek the Nth parent, then above.
Responding over here, I have gained some new insite, or am I just rehashing things, # things
I have built a cascade that uses a macro, the # macro, and a keyword/phrase to return as a tooltip. Perhaps the cascade used could be described as “Tooltip for keyword/phrase based on virtual fields”
Nothing if disabled
Text provided in the macro over the keyword/phrase
The description field of a tiddler named keyword/phrase eg tooltip
Other nominated fieldnames of a tiddler named keyword/phrase
Look up keyword/phrase in a data tiddler named fieldname (defaults to description)
If no entry here use default value from fieldname tiddler?
empty message (optional)
For this thread I want to point out specifically in the above;
Look up keyword/phrase in a data tiddler named fieldname (defaults to description)
So what is happening is a given “fieldname”, associated with a given “tiddler title”, if it does not contain any value, with this macro it will look for the “fieldname” tiddler, which is a data dictionary, lookup the “tiddler title” entry to retrive a value for a “virtual field”. Areguably at least via this macro then you can assign a field a value, without touching the tiddlers actual field.
Background
If you see in the above I used a particular cascade, currently its implemented in a nested if then else structure in a procedure. If we look at scott’s comment we can see that arguably there is another cascade, that walks a parent tree, looking for a value (he says using get).
Innovative idea?
It is often possible to define a cascade within a function to follow a cascade process to return a value. lets call these “cascade functions”. Cascade functions can be substantialy different and very sopisticated. Imagin however a set of “functions and macros” that do different things such as;
Simply return a value
Put the returned value as text in a mouse over tooltip
Use the returned value as a title
and provide a link to it
preview the named title
Wikify/transclude the returned value
Use the returned title as a footnote
… and many more …
Now imagin, if everyone of these functions and macros will allow you to nominate which “cascade function” to use by default, this allows you to drive anyone of these above “functions and macros” with whatever “cascade function” you want.
The above functions and macros can be built into a useful resource
The community can develop a range of “cascade functions” to meet different needs
We can also ask the community for particular “cascade functions” to meet different needs
Create a defacto standard around the writting of “cascade functions” and the macros in which they can be used, the “functions and macros, that can use cascade functions".
Relationship to this Topic?
The flags implimentation would benifit from having a defined “cascade function” and a series of “functions and macros” developed for flags could be reused for other cascade functions eg;
Flag pill
Add/remove flag
List items flagged
Supporting Editor toolbar buttons
etc…
This also continues the original idea
No touch, without editing or Changing the tiddler, even creating a tiddler.
That is under a defacto standard the “flags solution” will reusable, and provide reusable code to other “cascade functions”, and them to the “flags solution”.
I don’t have time to read this carefully, and probably won’t before the weekend, but I wanted to respond to this:
Note that this is not something that exists. It’s something I believe we can build if we want to spend the effort. I see a lot of potential value, but it’s also quite a large undertaking. The individual pieces (like a get' alternative to get) should be easy enough, but I expect there would be a lot of them!
I am not sure, at least in the case of the ancestors and decendents operators we can collect the set of titles, after all the list of titles should be “descreat” and then you can do your conditional tests until the first is found.
The Kin operator is an even more inclusive solution.
My reply here All I want for Christmas - #16 by TW_Tones touches on this indirectly such as using simple nesting to address this logic. Functions that return a list of titles that we can then operate on, do a form of “flatening”, by turning part of the algorithium into a “flat list” then operate on that list.
Simmilarly if we could parse or walk content and generate sophisticated data structures and then query them it would be quite performant way to handle this.
I do expect I am overloading this thread, however as I come to understand this no touch listing, I am gaining more insight and the filters/functions needed to handle no touch flags.
Yes I am continuing a “speculative wandering”
Recent Observations
I love relink and continue to use it, but I can also see how it may give rise to some distraction, the reason is that there are other ways to handle a subset of the problems that relink addresses. With the right tools a title can be stored only in one place and referential integrity retained.
Despite this relink retains an importiant role here
There are opportunities to leverage the algorithms in no-touch flags to make a robust set of relationship tools that has “minimal touch”, ie store the relationship in one place but have it visible in more then one place.
As recently discussed the idea of virtual fields, where we can provide a field=value pair as if we edited a given tiddler, but have not. This is difficult to apply to the core as it already has its methods, arguably it has a type of technical debt. However if we introduce a new set of algorithms we can build a solution quite capable of handling this, allowing for virtual fields to be assigned.
Is the value in a real field?
if not is it in a virtual field for the currentTiddler?
if not shall we use the value in a named tiddler?
if not is their a global default?
Realisations
Careful generalisations of the ideas coming from recent observations will provide a powerful set of algorithms that would facilitate a number of ideas that I have being involved with in recent weeks. But I know see the opportunity for some powerful “entity relationship” tools. I will expand on this once I do some more POC’s
You could add a list-before or list-after field to determine where on the view Template it appears.
So now on any nominated tiddler on which I apply the SubToc flag (no touch on nominated tiddler) the SubToc tiddler (above) is displayed.
I raise this here because in relation to Tag ($:/tags/ViewTemplate) allowed to "disregard" some tag-children we could have a “disregard” flag for any tiddler tagged $:/tags/ViewTemplate and with a small mod to the view template (as has being proposed) globally disregard a viewTemplate tiddler, for any tiddler so flagged.
There is also an opportunity to give a specific tiddler its own disregard list.
The SubToc flag above is an example of the opposite to disregard (rule out), eg regard (rule in)
Next;
No touch filter driven test (as discussed previously)
