Tiddler Hooks may ease the path to customizing the display/viewing of tiddlers.
For beginners, editing the pieces that make up a TiddlyWiki ViewTemplate is a non-trivial task. This post offers an easier and alternative (non-replacement) mechanism for achieving the same outcome.
Whether this mechanism should be taken up by the core I will leave to others. The proposal here is merely a Request For Comment (RFC).
We edited the core tiddler $:/core/ui/ViewTemplate/body and added two hooks. We used one of those hooks to detect when a tiddler with the tag Common Operators is shown so we can display an informative (though pretty unnecessary) message.
Afterword
You can, of course, name your hooks anything you like though it certainly helps to “self-document” by naming them in accordance with their position in the TW structure (which is not necessarily a clue to their purpose). To address that, make the hook call a macro of the same name and from within the macro, call other macros named for their purpose(s).
After years of trial and error I think my method is pretty close to yours in this area (assuming I’m understanding you correctly), though I just add the templates using $:/tags/ViewTemplate tags vs. hacking the core $:/core/ui/ViewTemplate/body tiddler (I prefer to not edit core tiddlers unless absolutely necessary).
So, I add a $:/custom/template-top tiddler that I tag $:/tags/ViewTemplate and then a $:/custom/template-bottom tiddler that I tag $:/tags/ViewTemplate and then position them using the tag drop-down. Within those tiddlers are lines that all look like <$list filter="[all[current]tag[Project]]"><$transclude tiddler="$:/custom/templates/project" mode="block"/></$list>. In my organizer I have templates for Projects, Tasks, Contacts, Initiatives, etc…
I will say that I’m expecting this new “Cascade” feature that I hear is coming in 5.2.1 to influence how I do this in the future. The one flaw in this process is that I can’t selectively hide stuff as easily, only add things. I hope Cascade improves this.
I am not a fan of modifying core tiddlers, either. This is merely a demonstration of a technique I adopt in my own infrastructure but sharing that in an expedient manner would be almost impossible. The best way to prove the concept is to use tiddlywiki.com and the most visible and pervasive tiddler structure in a regular tiddlywiki is the core view template.
In my own tiddlywikis I have large-grained tiddlers called “SectionViews”. They provide hooks that I use differently in different wikis. IOW, I do not need to modify system tiddlers at all.
I think it is a terrific idea, but that isn’t what I need.
What I need, using $:/core/ui/ViewTemplate/body as the case study:
I need that tiddler to be componentized to the hilt.
Then I need an ability to specify an override. Something that does not replace$:/core/ui/ViewTemplate/body, but overrides it with my own creation.
Say $:/my/ui/ViewTemplate/body.
And it transcludes the $:/core/ui/ViewTemplate/body components, whichever ones I want, in whatever order I want, wrapped by whatever custom stuff I’ve created.
The way we modify the templates and when can get complex really quickly. I have being imbedded in this somewhat including recently. Here are some notes that may help on this.
But First the original post of @CodaCoder . I to have done similar things in the past. The key to your solution seems to be, before and after the body conditional content but it seems to me the same can be done with a simple two tiddlers $:/tags/ViewTemplate list-before and list-after $:/core/ui/ViewTemplate/body, I stand to be corrected, but think this may be true.
In conversations with Jeremey some new operators are coming that will allow the writing of the core view template for much more hackability. these are;
The key possibilities in the use of the cascade filter and an updated Core user interface on the pre-release , is you can trigger the following programaticaly;
Alternative body templates eg $:/core/ui/ViewTemplate/body
Alternative “whole” View/edit Template (a view edit template, somewhat equivalent to alternative layouts).
The balance of the above improvements will allow you to do much smarter things in templates and even in an alternative $:/core/ui/ViewTemplate/body basically rewriting the original @CodeaCoder solution without overwriting core tiddlers and more extensible.
These are going to allow the view edit templates (or you own by design) to respond to more customisation without template modification ActionSetMultipleFieldsWidget, programaticaly set 0-N fields new SetMultipleVariablesWidget programaticaly set 0-N variables
I expect what will come out in the wash is additional improvements to the view/edit templating mechaisium, reducing the need for core overwrites.
@Charlie_Veniot the new cascade filter and its use in the templating mechaisium is a conceptual leap, and despite being somewhat involved in the discussion, it is not strait forward to conceptualise, Mario does a good job at that Github link.
I do think it will be easier to understand when it matures and we have good use case examples. And easier to chew
The post is not about hacking the ViewTemplate, as I explained to @Mohammad. I used that as a means to and end, merely so I could use tiddlywiki.com as the demonstration test bed.
Is more complex to me than a new tiddler tagged $:/tags/ViewTemplate and list-before or after (attentively the tag drop down to reorder), and will cope with wiki upgrade but hey we all have different perspectives.
Sure, and I like your section idea, however I am interests in defining different tiddlers and I would use your method/algorithium in a sperate body template (especially with the new features pending) rather edit $:/core/ui/ViewTemplate/body.
Let us not get in a twist, this is all at moment of flux, and “interesting times”.
