A return to blogging with Tinderbox, with questions

Tinderbox Tasks
1

For 2022, I’m planning to use Tinderbox for my “daily notes” blog, so I started with a brand new Tinderbox file for managing a simple blog. The first revision is now at daily.baty.net.

Before I get too deep into this, I’d like to make sure I’m doing things correctly. Much has changed since I last did this in 2013.

My first question is about where to put action code/functions/macros/etc.

As a practical example, I’ve always considered the way note icons in outlines indicate age and size to be a brilliant and under-appreciated feature of Tinderbox…

icons

I’d like to mimic this on my archives page.

I started by adding a conditional in the export template which shows an image icon if the post has an $Image. For other notes, I’d like to show an icon indicating the length of the note. (I don’t care yet if they yellow with age as they do in Tinderbox, as cool as that is.)

Generically, I think want a function something like “fnGenerateNoteIcon()” which returns a file name or path or HTML for rendering the correct icon, based on the note’s length and presence of an $Image attribute. Is this a function? A macro? I’m looking for guidance on the modern approach to something like this.

Thanks

1 Like
2

This used to be a macro, and it still could be.

The simplest implementation would be a rule, which each post would inherit and which would choose the image name.

if ($TextLength>1000) {
      $ImageName="Lots";
      }
if ($TextLength>0 & $TextLength<=1000) {
    $ImageName="Some";
    }
if ($TextLength==0) {$ImageName="None";}

We could also do the same thing with $Age, setting it to “New”, “Aging”, or “Old”. Then, we could export the desired markup:

<img href="^value($ImageName+$Age).html">

Nowadays, I’d be tempted to move some of that complex logic into a function.

3

Thank you, Mark. My first thought was that I didn’t want to store the result in an attribute, but rather just render it as part of the archive export, since it only happens for that one note/file and only during export, so why lug around a user attribute (and supporting rule(s))? Then I realized I don’t know how to do it cleanly without using an attribute, so I should probably start with your approach. Either way, this might be good opportunity for me to learn how (and when and where) to use functions. Thanks again.

4

The cost of an attribute or two is modest. But you could also use a var, and that might (as you say) be a little bit neater.

1 Like
5

It’s great to see you here again, @jackbaty – I always enjoyed your posts on the now-defunct legacy Tinderbox forum.

6

Nice of you to say, thank you! My relationship with Tinderbox has been intermittent for the past several years, but only because I became infatuated with iOS and Linux. Now that I’ve purged myself of those urges and whittled my computers down to a single new MBP, I can dive right back into Tinderbox. It’s just so good.

I’m currently neck-deep in revamping and combining my Daybook and Blogging Tinderbox files. I’m slowly catching up, but wow have things changed :). I’m often confused, but am having a ball!

2 Likes
7

Selcome back.

A tip, when doing so, is to review all the legacy code (i.e. what worked when first written) and to update it†. Unquoted strings, non-$-prefixed attribute references, and the like should be treated as if not working to save you another update soon. Given that most of these have been on the naughty step for c.10 years (older than many apps!) it’s not exactly a new task, if tiresome for those of use with old code.

†. If in doubt, by all means post samples here.

8

Thanks, Mark. In an attempt to avoid dragging along outdated work, I started with a brand new file and am rebuilding it from scratch. (It’s been a long time since “Flint” was a thing!) While I probably still have some old, bad habits, at least the new file won’t start with a bunch of copy-and-pasted legacy code :).

1 Like
9

Flint :open_mouth: . Actually I’ve plenty of Flint docs resting on my h/d.

Yes, a new file is a good way to go, for just the reasons you describe. Just like an author forced to kill off a prominent character, re-structuring a TBX doc can be aided by a non-nostalgic take on the relevance of past (code) efforts.

10

Thanks for the shout-out at your place! :blush:

11

Dave, your blog is one of the things that inspired me to get back into blogging with Tinderbox. So, thanks!

1 Like