TW5: textfield in a template

[Odin Jorna]

Hello all!

First-time poster here. I have used tiddlywiki before to make a simple bookmarkingwiki with gifs of dance moves I want to learn. Now I am trying to build something bigger: a personal notebook. 

In this notebook, I want to make tiddlers of people I know, and I am using a tiddler as a template (tagged it with $:/tags/ViewTemplate) so that I can put in the relevant data in the fields and the template will make a nice tiddler for me. I am using transclusion mainly for the fields and HTML for the layout of the template.

The problem I am running into is that I don't have control of where the contents of the text field are placed into the template. I want to use the normal text box to put down my notes, thoughts and any other information that isn't general contact details in the tiddler. But then it automatically dumps the text on top of the template in the person tiddler. If I transclude {{!!text}} at the position I want the text show up it works, but then I still have the text on top of everything. 

What would be a way to fix this? I have included an empty tiddler with the template-tiddler and an example contact, so you can see what I mean. I have to say that I am not really a programmer/coder and that I only have a little experience with HTML and CSS because of messing around in my free time.

Hoping someone has some time to help.

With kindest regards,

Odin

[Eric Shulman]

On Tuesday, January 7, 2020 at 11:49:41 AM UTC-8, Odin Jorna wrote:

The problem I am running into is that I don't have control of where the contents of the text field are placed into the template. I want to use the normal text box to put down my notes, thoughts and any other information that isn't general contact details in the tiddler. But then it automatically dumps the text on top of the template in the person tiddler. If I transclude {{!!text}} at the position I want the text show up it works, but then I still have the text on top of everything. 

The tiddler "view" is composed on several parts, each of which is tagged with $:/tags/ViewTemplate.  You can control the order in which those parts are displayed.

To see the current order, you can go to your custom template tiddler, and click on the "tag pill" for "$:/tags/ViewTemplate".  This will display a dropdown list of all tiddlers with that tag.  The order shown in the list is the order they will be displayed when viewing a tiddler.

There are several ways to change the order.  This is (briefly) documented in https://tiddlywiki.com/#Order%20of%20Tagged%20Tiddlers

For your purposes, the easiest approach is probably to add a "list-before" field to your custom template, with a value of "$:/core/ui/ViewTemplate/body".

This will cause your custom template to appear before the standard "text" content of the tiddler.

Q.E.D.

enjoy,

-e

Eric Shulman

TiddlyTools.com: "Small Tools for Big Ideas!" (tm)

InsideTiddlyWiki - http://www.TiddlyTools.com/InsideTW

 

[Odin Jorna]

Hi Eric!

Thank you for the explanation of how the view tiddler is made of and how the ordering works. That clarified a lot.

After trying out the list-before field, the text does change to after the template. But what I was looking for was getting it inside the template. Inside, there are some  <div class="flex-row"> and <div class="flex-col-1 "> that sorts the view into rows and columns. What I would like is to have the text inside the column. In the example file, I placed a {{!text}} at that spot. 

Do you think that is possible?

Op dinsdag 7 januari 2020 21:10:18 UTC+1 schreef Eric Shulman:

[TonyM]

Odin

Where you want text to appear in a html template you can use

<$transclude mode=block/>

Which defaults to currenTiddler and the text field.

Not sure if this solves your problem but it is another way.

Tony

[Joshua Fontany]

I think I have a solution for this one. The ability to hide/replace the default text field is a bit cumbersome atm. You can hide the text-body by setting the `hide-body` field to "yes". And we can add new "sections" with `$/tags/ViewTemplate`, but unless we dig around and copy the $reveal code from another template section that will not be consistent with the Collapse state.... Yeah. Complicated.

If I change the `$:/core/ui/ViewTemplate/body` tiddler slightly, we can move the "tiddler-body-default" wikitext to a macro in the same tiddler:

```

\define tiddler-body-default()
<$list filter="[all[current]!has[plugin-type]!field:hide-body[yes]]">


<$transclude>


<$transclude tiddler="$:/language/MissingTiddler/Hint"/>


</$transclude>


</$list>
\end

```

And re-write the body of the tiddler like so:

```

<$reveal tag="div" class="tc-tiddler-body" type="nomatch" stateTitle=<<folded-state>> text="hide" retain="yes" animate="yes">


<$list variable="bodyTemplate" filter="[all[current]subfilter{$:/config/ViewTemplate/Body}]" emptyMessage=<<tiddler-body-default>> >


<$transclude tiddler=<<bodyTemplate>> >


<$tiddler tiddler=<<bodyTemplate>> >


<$transclude tiddler="$:/language/MissingTiddler/Hint"/>


</$tiddler>


</$transclude>


</$list>


</$reveal>

```

Then we can use an array of filters to check for tags, type, or any other way you want to trigger a custom view template, and you can have more than one resulting bodyTemplate titles output and it's all nested in the correct $reveal widget, etc. Even better, you can use the `<<tiddler-body-default>> macro ANYWHERE in your own templates to get the default text-field to show up in that spot. Here is my current `$:/config/ViewTemplate/Body`:
```

[tag[$:/tags/Macro]then[$:/plugins/joshuafontany/core/ui/ViewTemplate/body/macro]]
[tag[Glossary]then[$:/plugins/joshuafontany/silatglossary/ui/ViewTemplate/body]]
[match[Test]then[$/plugins/joshuafontany/core/ui/ViewTemplate/body/TEST]]

```

Which as you can see, uses the `$:/plugins/joshuafontany/core/ui/ViewTemplate/body/macro` tiddler as the body-template for all Global Macro tiddlers. This template looks like:

```

<pre><code language={{!!type}}><$view field="text"/></code></pre>

```

Which is a bit overkill, but is exactly how, internally, the `application.javascript` tiddlers are rendered. But this means I no longer have to click edit on every Macro tiddler just to re-read it for bugs, etc. I'm going to expand this technique to render other custom tiddler types for other projects.

Oh, yes, final note. The Type field can and will definitely over-ride this custom rendering, as that's done internally using the wiki's Parser methods. Also, I'm not sure if this is 100% backwards compatible, but the only thing I can possibly think of it changing are the Numeric Values output by the Qualify Macro (as these depend on how many and which tiddlers the current content is being rendered "through").

I think I will expand this to allow for a tabbed interface in the Draft Mode UI, with the standard Text Editor in one tab, and other content in other tabs. I can also use this to extent the Title field to allow for a custom Name (short & human readable, see plugins) that will display full size (if present) and which pushes the full Title down to a line of smaller text.

Best,

Joshua Fontany

[Joshua Fontany]

Oooooh, wow. This is incredibly powerful.

PR is up. I have attached a *.json bundle with the tiddlers I am using to test the rendering. 

The Title and Subtitle overrides have a `name` field, like a plugin, and this triggers a custom view template for each that pushes the title into the subtitle, and renders the Name in the <h2>title</h2>. Both obey the Titles-a-Links setting in $:/Config > Settings.

I have also attached a *.json bundle with just the changed shadow-tiddlers, so you could actually try this out on tiddlywiki.com by dragging both to a tab with it loaded.

https://github.com/Jermolene/TiddlyWiki5/pull/4681

Best,
Joshua Fontany

[TonyM]

Joshua,

Can you share what the implications are in your mind?

I now have Timimi on Chrome, and read the forum in chrome. I found a nice workflow. 

• Download the json files to a my scratch folder, but they sit in the browser footer tray
• Go to Tiddlywiki.com drag the json files from the footer tray on top of tiddlywiki.com
• I took the extra step of downloading tiddlywiki.com, double click in the download tray to open in a tab and drag the json to that for a Timimi savable test.

You idea seems like an advance but I need to re-conceptualize this in relation to all the things I already know about viewTemplates, and how I would do what I already do.

If we are modifying the view Templates there are a few other hackability issues that would be nice; Given the area you are modifying it makes sense to raise them here;

• Tags to add items to the subtitle
• Ability to display a prefix or suffix to the title
• eg if chapter number is available display that before title
• even use the tiddlers position in a tag list to obtain the number
• Optional Extra a new float right toolbar under the existing one to add contextual buttons
• Ones that appear of disappear on various tiddler or wiki wide conditions
• We can already do this with conditional code in buttons, but it would help sort them from standard buttons if they had their own place. 

Either you could incorporate these changes in your templates, with a view to adding them to the core as well.

Regards

Tony

[Saq Imtiaz]

@TonyM in short this allows you to completely override and replace any part of the ViewTemplate (or Edit) that you want to.

Look at Joshua's example for $:/config/ViewTemplate/Body from above.

[tag[$:/tags/Macro]then[$:/plugins/joshuafontany/core/ui/ViewTemplate/body/macro]]
[tag[Glossary]then[$:/plugins/joshuafontany/silatglossary/ui/ViewTemplate/body]]
[match[Test]then[$/plugins/joshuafontany/core/ui/ViewTemplate/body/TEST]]

For the subtitle you would use similar filters in $:/config/ViewTemplate/subtitle

[TonyM]

Post script,

A Hide-body variable/macro that would override the hide-body field if it is set, allowing one template to turn it off or on programmatically as required.

Regards

Tony

[TonyM]

Saq,

Thanks, 

So it externalises the determination of the view template "pieces" to use given provided conditions?

This seems like a very helpful hack, Using import variable on such templates we would also be able to reduce the global macros needed for specific macros for a given template. 

I would like to use this to replace the edit mode field handling with a customised one on particular tiddlers.

I use a tiddler field called object-type each value of which may have its own view and edit templates, a template tiddler, and more so this may make this easier without modifying the Viewtemplate order to accomodate additions.

Regards

Tony

[Saq Imtiaz]

So it externalises the determination of the view template "pieces" to use given provided conditions?

Exactly

 

I would like to use this to replace the edit mode field handling with a customised one on particular tiddlers.

I've been doing exactly this using one small part of this proposed change, but that required editing PageTemplate/story so this a very welcome change.

[Joshua Fontany]

Yeah, this is probably my favorite hack I've ever come up with. Its so easy to customize pieces of the Tiddler-in-the-Story-River.

Right now I just got a tabbed editor working on all [tag[Glossary]] tiddlers, that auto-hides the Fields section in an accordian $reveal widget, and has the default editor on one tab, and my custom-fields editor on the next. This has edit boxes for the `aliases` field, as well as every field found in the `_language_list` field. It all just works. Setting up a set of test tiddlers you can play with now.

Best,
Joshua F

[Joshua Fontany]

Here is a json of all the tiddlers necessary to test this out, both the changed sysetem tiddlers, and the custom templates and settings tiddlers I have been using to test this new system. If you drag everything into a fresh wiki, and then open the "Adat 1" tiddler, you should see that the Fields section is now in a toggle-able hidden $reveal widget, there is a toggle link/$button floating to the right of the Type field, and the BODY has two TABS - one with the normal Edit Text stuff, the other with my custom Languages fields for the glossary I am building.

Best,
Joshua F

[Joshua Fontany]

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

[clutterstack]

I have not played much with this yet, but I keep coming back to this thread. Now that I'm getting over the hangover from discovering what filters can now do, this is the Next Big Thing as far as I'm concerned.

I hope to find time to test-drive this soon.

Cheers,

Chris

[Jennifer S]

This thread was very helpful as I have aimed to understand how to have different layouts for different kinds of tiddlers, ones which superceded the amount of flexibility afforded by the ordering of tiddlers tagged as a view template, which include different positions for the text field itself in relation to other fields. 

Eventually I found another thread that explains the new view template "cascade" feature:

https://talk.tiddlywiki.org/t/how-to-hide-tiddler-body-if-a-particular-viewtemplate-is-applied-on-that-tiddler/2509/5

It's now quite easy to add your own template and rules to the waterfall, without editing the core, in a manner which I believe Joshua's "hack" initially elucidated.