Hi everyone,
Let me explain the method I am using to do these custom templates. I am not
changing the existing $:/tags/ViewTemplate or $:/tags/EditTemplate
architecture at all. The $list widget that builds each tiddler in the
story-river still does exactly that. What I have done is gone into key
system tiddlers with those tags and found the "bare minimum" code used to
render the content, moved that to a macro, such as `\define
tiddler-body-default()`. Then, in that place in the system-tiddler, I put
(cutting out the debug and "missing tiddler" fail-safe code):
<$list variable="sectionTemplate"
filter="[all[current]subfilter{$:/config/ui/ViewTemplate/body}]"
emptyMessage=<<tiddler-body-default>> >
<$transclude tiddler=<<sectionTemplate>> >
<$/list>
This checks the $:/config/ui tiddler specified for a series of filters, and
uses those titles as sections. BY DEFAULT this will return empty and place
the original code back using the `emptyMessage` parameter. Because the list
hosting these `sectionTemplates` exist in the tiddler defining the
<<tiddler-body-default>> definition, I can use that macro anywhere in my
own templates to render the default __whatever__, be that into a tab, a
$reveal widget, a new <$div> with a specific class or id value that is a
filtered translcusion (triple braces), etc. So I can insert or hide/show
the default chunk of code within my own templates. So my glossary template
tiddler is as simple as:
<<tiddler-body-default>>
<<glossary-item>>
The <<tiddler-body-default>> code is defined within the
$:/tags/ViewTemplate "body" tiddler, and the <<glossary-item>> code is
defined in a global macro tiddler ($:/tags/Macro) because I re-use it in
other templates.
Because we are using the `subfilter{configTiddler}` operator, each filter
run in that config tiddler gets fed the <<currentTiddler>> value. Then, the
output is collected and returned as a title-list. This is used to render
the new UI for that section. The use of filters allows __whatever__ custom
triggers, conditionals, etc, you can conceive by using the current filter
operators. I am currently using the existence of a tag for both the
Glossary and $:/tags/Macro custom bodies. I will be building UI for my
Youtube, Vimeo, etc bookmarks to transclude their player-embed code by
grabbing the right parts from their link URL, and drive that on
[tag[Bookmark]regexp:url<youtube-domain>], or
[tag[Bookmark]regexp:url<vimeo-domain>], or whatever.
I realize now that one of the things that sparked this idea was listening
to Jeremy on one of the tiddly-hangout videos talk about how robust the
filter operator "language" has become now, and that many things in the core
that were done in other ways could be revisited using Filters as the
primary syntax. This plus seeing some of the really cool stuff being
developed recently, and getting a better sense of how TW renders things
"under the hood". Thanks for trying this out, and for all the feedback so
far!
Best,
Joshua Fontany
On Tuesday, May 26, 2020 at 5:33:19 PM UTC-7, TonyM wrote:
>
> Mario,
>
> As you say the view template sets all the elements tagged
> with $:/tags/ViewTemplate from title to subtitle, buttons etc...
>
> There are cases when we want to alter one of these only, such as the body,
> there are other times we want to add or remove one or more items, often
> conditionally/programmatically.
>
> When altering only the body we do not want the standard body to display so
> we want to replace it, on other occasions we may want to add something but
> hide-body conditionally/programaticaly.
>
> I think we need a little more flexibility here.
>
>
> - Another view template case is in a tabs internal navigation as an
> example, we may want to hide only the subtitle and control buttons to view
> tiddlers within tiddlers.
> - Also I see value in displaying alternate story's inside other
> tiddlers (with alternate viewtemplates), then choosing to make it the
> current story, eg a project story.
> - It seems to me we may need to enhance the way view and Edit
> templates are nominated, via both field or variable in addition to tags.
> - Perhaps we could use different templates for read-only view update
> and edit with a global or local tiddler override settings. I code this
> myself but core support would be smart and very few bytes would be needed.
> It would simply provide a mechanism.
>
> Regards
> Tony
>
>
>
> On Tuesday, May 26, 2020 at 7:12:28 PM UTC+10, PMario wrote:
>>
>> Hi,
>>
>> That's an interesting approach. ... I did a very short 2 minute test. ...
>> So I'm not really sure how everything works.
>>
>> ----------- Just some thoughts
>>
>> At the moment the TW ViewTemplate and EditTamplates are "stackable" and
>> changeable, without modifying the core tiddlers.
>>
>> That means, If I want to create a new element, that is part of the
>> existing UI, I only need to tag a tiddler $:/tags/ViewTempate and it will
>> be added at the end of the list.
>>
>> If I want it to be on a different position I need to add the field named:
>> list-before or list-after.
>>
>> IMO this type of functionality needs to stay. It needs to be possible, to
>> use whatever is active and only apply the "differences" to the elements I
>> want to change.
>>
>> ---------
>>
>>
>> At the moment ViewTemplate/title also contains the tiddler-toolbar. I
>> think this is wrong. It should be at least 2 independent elements.
>>
>> So if we change basic the core UI elements, we should make it even more
>> flexible.
>>
>> -mario
>>
>>
>>
>>
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywikidev/dc0ff3ff-c855-48f3-813d-f1c960889e0d%40googlegroups.com.
