I appreciate the wariness at adding more complexity, this has turned out to 
be pretty complex already... 

I took a stab at this, and collecting a set of filter runs from multiple 
tiddlers based on a tag and then getting them all to behave for the 
`subfilter<templateFilters>` operator is very brittle (breaks easily).

My mod allows you to conditionally over-write the basic contents of certain 
templates - and that was not possible without completely overwriting the 
whole template shadow tiddler previously. I think I can extend the 
`subfilter[]` operator to accept a suffix, like 
`subfilter:tag[$:/config/ui/ViewTemplate/body]` to run through it "behind 
the scenes."

This keeps the wiki-text changes to the core ViewTemplate/EditTempalate 
tiddlers minimal, instead of adding more nested $wikify widgets or 
whatever. I think this is worth it because it leverages an existing concept 
in the user's mind, that "tag order controls tiddler-template-section 
rendering order".

I am sketching out a design for an RPG Campaign manager, and I really want 
it to be able to support both "localization", and the display of multiple 
game-system's "character sheets" for a single "Character tiddler". This is 
a complex problem, but I think we're approaching a good solution. I would 
want it to be flexible enough that if a user starts with one ruleset 
installed, they can install other ruleset/UI packages and also customize 
their wiki's own tiddler-UI, and not worry about manually resolving clashes.

Lets see what I can do with the `subfilter[]` operator. :D

Best,
Joshua F


On Thursday, May 28, 2020 at 11:12:45 AM UTC-7, Saq Imtiaz wrote:
>
> Two quick thoughts:
> - I fear adding anymore complexity to the template logic is going to 
> result in this being deemed plugin territory and not suitable for the core. 
> I might be wrong, but past experience makes me cautious. Right now I see 
> the pull request as adding a few hooks for more extensibility that is 
> hopefully backwards compatible, rather than introducing a new core 
> mechanism which adds complexity and probably breaks backwards compatiblity.
> - A user that wanted to could still introduce tag based logic in their 
> config tiddlers.
>
> I haven't had the chance to think about it this in a lot of detail so I 
> may be missing something, hence the request for a concrete example.
>
> On Thursday, May 28, 2020 at 7:37:33 PM UTC+2, Joshua Fontany wrote:
>>
>> 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/ViewTemplate/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/d069a383-4d2d-4d3a-acb7-ecc9cd02cca3%40googlegroups.com.

Reply via email to