search

TiddlyWiki / TiddlyWiki5

A self-contained JavaScript wiki for the browser, Node.js, AWS Lambda etc.
https://tiddlywiki.com/
Other
8.06k stars 1.19k forks source link

[IDEA] allow individual tiddlers to override ViewTemplateBodyFilter cascade with a view-template-body field value #6952

Open ericshulman opened 2 years ago

ericshulman commented 2 years ago

Is your feature request related to a problem? Please describe. I have some stylesheet tiddlers (tagged with $:/tags/Stylesheet) that I want to have rendered as regular wikitext (using $:/core/ui/ViewTemplate/body/default) -- instead of applying the pre-defined TWCore cascade template, $:/config/ViewTemplateBodyFilters/stylesheet which uses $:/core/ui/ViewTemplate/body/rendered-plain-text

Describe the solution you'd like First, add $:/config/ViewTemplateBodyFilters/body-template, tagged with $:/tags/ViewTemplateBodyFilter, containing

[has:field[body-template]then{!!body-template}]

and add field list-before with a blank value, so that this tiddler will always be processed first in the ViewTemplate cascade.

Then, in the desired tiddler, add a field body-template specifying the title of the desired "override" template. To use the default body template, specify either $:/core/ui/ViewTemplate/body/default or an empty field value.

Describe alternatives you've considered At first, I created a tiddler named $:/config/ViewTemplateBodyFilters/TiddlyTools, tagged with $:/tags/ViewTemplateBodyFilter, containing

[tag[$:/tags/Stylesheet]then[$:/core/ui/ViewTemplate/body/default]]

with list-before set to blank. This works, but is overly-broad, as it affects all stylesheets, including the TWCore shadow stylesheets.

I also tried defining a ViewTemplateBodyFilters cascade containing

[match[MyStylesheetTitle]] [match[AnotherStylesheetTitle]] +[then[$:/core/ui/ViewTemplate/body/default]]

which also works, but is overly-brittle, as it depends upon the specific titles listed in the filter.

pmario commented 2 years ago

I did have a similar problem while playing with the palette-manager. ... I think I found a generic solution, without the need for the core to define a bunch of hardcoded fields for every cascade we use at the moment. ... I needed to modify the tiddler-title cascade.

I'm not 100% sure, if my mechanism will work for you. I'll need a bit more testing and will post some code if it works out, as I think it does.

ericshulman commented 1 year ago

Can we re-visit this body-template idea? There are actually quite a few use-cases where overriding the default ViewTemplateBodyFilters cascade is desirable (e.g., rendering wikitext when viewing specific $:/config/* tiddlers as well as $:/tags/Stylesheet tiddlers).

I'm not suggesting a generic override mechanism for every cascade we use... just the use of a body-template field for overriding the default ViewTemplateBodyFilters. However, if @pmario has worked out a generic override solution, then I'd like to review it to determine if it fits my use-cases.

Jermolene commented 1 year ago

Hi @ericshulman I have no objection to your proposal in the OP. Perhaps the field should be "view-template-body" to make its usage clearer.

pmario commented 1 year ago

... However, if @pmario has worked out a generic override solution, then I'd like to review it to determine if it fits my use-cases.

I'll look into it and post the code. ... Will be interesting if I still understand it after some time not visiting it :)

pmario commented 1 year ago

@ericshulman Your usecase is a bit different than mine, but I think the problem I was facing is also valid by yours... You did not mention it. ... But it's there too.

My usecase and problem came up while developing the PaletteManager edition: https://wikilabs.github.io/editions/palette-manager/

To reproduce the problem:

As you can see, If I would "hardcode" the [[$:/core/ui/ViewTemplate/title/default]] title, the system prefix would be not used. So it's important to use the $:/config/ViewTemplateTitleFilters/palette first and then call the original cascade again.

image

The code can be found at: https://wikilabs.github.io/editions/palette-manager/#%24%3A%2Fcore%2Fui%2FViewTemplate%2Ftitle%2Fpalette

I'm not sure if that makes sense, but I think it's also important for Eric's usecase, since users can add more cascade elements to the configuration, that are not known at the moment.

ericshulman commented 1 year ago

My proposal is intended to provide a simple override of the ViewTemplateBodyFilter cascade logic for a given tiddler by allowing that tiddler to explicitly specify which template should be applied (or use a blank value to fall-through and apply the default template).

This permits certain stylesheets tiddlers to render their content as wikitext rather than plain-text because those tiddlers also contain interface elements that can be used to control how their CSS is to be applied.

Your proposal is different, in that it seeks to extend the cascade handling to permit more complex conditional logic for determining which elements are to be rendered by the template selected by the cascade.

Both approaches have merit, but I think they address distinct use-cases.

ericshulman commented 1 year ago

Hi @ericshulman I have no objection to your proposal in the OP. Perhaps the field should be "view-template-body" to make its usage clearer.

I agree. I will change my current custom cascade definition to use a field named view-template-body rather than body-template.

ericshulman commented 1 year ago

bump

Jermolene commented 1 year ago

Hi @ericshulman I am concerned that we don't have a precedent for a field containing the title of a template. We have things like the "hide-body" and "code-body" fields, but they are flags not template titles.

Would it be sufficient for your purposes to instead update the stylesheet filter in the cascade so that tiddlers with $:/tags/Stylesheet are not rendered in plain text if they have a "code-body" field set to "yes"?

[tag[$:/tags/Stylesheet]!field:code-body[yes]then[$:/core/ui/ViewTemplate/body/rendered-plain-text]]
ericshulman commented 1 year ago

Would it be sufficient for your purposes to instead update the stylesheet filter in the cascade so that tiddlers with $:/tags/Stylesheet are not rendered in plain text if they have a "code-body" field set to "yes"?

Using !field:code-body[yes] doesn't make semantic sense to me since I don't want to use the $:/core/ui/ViewTemplate/body/code template to render a $code-block. Rather, I would think that using something like !field:plain-text[no] would be more appropriate since the goal is to bypass the rendered-plain-text template in order allow the $:/core/ui/ViewTemplate/body/default template to fully render the wikitext of the tiddler.

In any event, that approach would only be applied to stylesheet tiddlers, which doesn't actually cover all my currently implemented use-cases. I also have some $:/config tiddlers that need to be rendered as wikitext (i.e., using the default view template) so that they can contain both the fields with current configuration values as well as a text field that provides a wikitext interface for setting those configuration values (see https://tiddlytools.com/#%24%3A%2Fconfig%2FTimers%2FSampleTimer for an example).

Although I could probably make do with a flag value like view-template-body="default" (and a corresponding cascade filter to apply $:/core/ui/ViewTemplate/body/default), my original proposal to specify a template title (or a blank value to use the default template) will provide much greater flexibility for enabling a wider variety of possible use-cases without needing a proliferation numerous custom "one-off" cascade items to support them.

pmario commented 1 year ago

@ericshulman I did have a look at the problem. I still think it is related to my usecase. but I didn't have enough time to create a solution. I did some Experiments but I'm not happy with them at the moment. More time and more experiments are needed