I think Tony has identified the one small "weakness" in the overall design, that it is run from a single config tiddler, and if it is adopted in the core and widely used, there may be "clashes" where plugins both have the config tiddler defined. The question of adding or ordering template "chunk" filters to the config tiddler isn't as big of an issue, as each filter run can be manipulated with the list-ops filter operators to reorder (if people want a UI for that its possible).
Would it be a better idea to collect the template filters via a tag? We could extend the "parent" tag, so for `$:/tags/ViewTemplate`, we could have all body-section filter-tiddlers tagged `$:/tags/ViewTemlate/config/body`. Then we would have to collect all of the filters into a variable before passing it to the `subfilter<configFilters>` operator. This would allow a using the more familiar tag-based ordering if multiple config tiddlers are defined and users would not have to re-order filters _within_ a config tiddler to change things at the 'section' level. Best, Joshua Fontany On Thursday, May 28, 2020 at 10:23:23 AM UTC-7, Saq Imtiaz wrote: > > @Tony can you please post a precise example - with code or even pseudo > code - of something you would wish to achieve, that you think is not > possible with the given pull request? > > Regards, > Saq > > On Thursday, May 28, 2020 at 9:17:19 AM UTC+2, TonyM wrote: >> >> Joshua, >> >> This seems like a great addition. But perhaps I can clarify this from a >> regular users perspective? I also follow it with a Question. >> Please tell me if I understand and my description is appropriate. >> >> *Description* >> Alternative Templates for View and Edit template sections. >> >> The Config tiddlers such as Tiddlers $:/config/ui/ViewTemplate/body >> and $:/config/ui/EditTemplate/body (more below) >> Can contain zero or more additional filters of the form; >> >> [condition[then[templatename]] >> >> >> Eg >> [tag[Glossary]then[templatename]] >> >> If one or more conditions generate a template name that template (those >> templates?) will be uses to display that "section" of the view Template. If >> not the default $:/core/ui/ViewTemplate/body will be used. >> >> - For example filters in $:/config/ui/ViewTemplate/body will >> determine an alternate template to use for the View Template Body >> - It make sense then that the templatename used should be similar to >> the section it replaces eg $:/owner/glossary/ViewTemplate/body >> - Perhaps the most common change will be that of the display of the >> body in tiddlers, with additional elements being added to tiddlers with >> the >> current tags. >> >> Standard View and Edit Template sections (for the record) >> >> 1. $:/core/ui/EditTemplate/body >> <https://tiddlywiki.com/#%24%3A%2Fcore%2Fui%2FEditTemplate%2Fbody> >> 2. $:/core/ui/EditTemplate/controls >> <https://tiddlywiki.com/#%24%3A%2Fcore%2Fui%2FEditTemplate%2Fcontrols> >> 3. $:/core/ui/EditTemplate/fields >> <https://tiddlywiki.com/#%24%3A%2Fcore%2Fui%2FEditTemplate%2Ffields> >> 4. $:/core/ui/EditTemplate/tags >> <https://tiddlywiki.com/#%24%3A%2Fcore%2Fui%2FEditTemplate%2Ftags> >> 5. $:/core/ui/EditTemplate/title >> <https://tiddlywiki.com/#%24%3A%2Fcore%2Fui%2FEditTemplate%2Ftitle> >> 6. $:/core/ui/EditTemplate/type >> <https://tiddlywiki.com/#%24%3A%2Fcore%2Fui%2FEditTemplate%2Ftype> >> 7. $:/core/ui/PageTemplate/story >> <https://tiddlywiki.com/#%24%3A%2Fcore%2Fui%2FPageTemplate%2Fstory> >> 8. $:/core/ui/ViewTemplate/body >> <https://tiddlywiki.com/#%24%3A%2Fcore%2Fui%2FViewTemplate%2Fbody> >> 9. $:/core/ui/ViewTemplate/plugin >> <https://tiddlywiki.com/#%24%3A%2Fcore%2Fui%2FViewTemplate%2Fplugin> >> 10. $:/core/ui/ViewTemplate/subtitle >> <https://tiddlywiki.com/#%24%3A%2Fcore%2Fui%2FViewTemplate%2Fsubtitle> >> 11. $:/core/ui/ViewTemplate/tags >> <https://tiddlywiki.com/#%24%3A%2Fcore%2Fui%2FViewTemplate%2Ftags> >> 12. $:/core/ui/ViewTemplate/title >> <https://tiddlywiki.com/#%24%3A%2Fcore%2Fui%2FViewTemplate%2Ftitle> >> >> >> >> >> New conditional template filters (for the record) >> >> >> 1. $:/config/ui/ViewTemplate/title >> <https://tiddlywiki.com/#%24%3A%2Fconfig%2Fui%2FViewTemplate%2Ftitle> >> 2. $:/config/ui/ViewTemplate/subtitle >> <https://tiddlywiki.com/#%24%3A%2Fconfig%2Fui%2FViewTemplate%2Fsubtitle> >> 3. $:/config/ui/ViewTemplate/body >> <https://tiddlywiki.com/#%24%3A%2Fconfig%2Fui%2FViewTemplate%2Fbody> >> 4. $:/config/ui/EditTemplate/body >> <https://tiddlywiki.com/#%24%3A%2Fconfig%2Fui%2FEditTemplate%2Fbody> >> 5. $:/config/ui/EditTemplate/type >> <https://tiddlywiki.com/#%24%3A%2Fconfig%2Fui%2FEditTemplate%2Ftype> >> 6. $:/config/ui/EditTemplate/fields >> <https://tiddlywiki.com/#%24%3A%2Fconfig%2Fui%2FEditTemplate%2Ffields> >> >> >> Question: Please consider >> >> - To introduce a new template one needs to append another filter to >> that in one of the config tiddlers. >> - To reverse this one needs to not the exact filter and delete only >> that line. >> - Unlike the tag method used on the view and Edit templates to add >> new elements the order may be important but not easy to change, at least >> programaticaly. >> - There is a strong possibility of one solution hitting another >> >> The Question: >> >> - I believe restoration of the ability to add and remove templates >> programaticaly through filters must be developed, Do you agree? >> >> In Closing: >> >> - I have a few easy and elegant methods to enhance this mechanism to >> address the Question I have raised, can I ask you to collaborate on >> making >> this a little more robust? >> >> Regards >> Tony >> >> On Wednesday, May 27, 2020 at 4:01:06 PM UTC+10, Joshua Fontany wrote: >>> >>> 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/6d472879-e11c-48f4-a493-e953dc3d7206%40googlegroups.com.
