[issue] Quirk in notes database solution I am developing

#9

Glad you got it working!

Incidentally, I’d started responding to your OP and scrapped it when I saw Eric was answering, but I did want to ask about this part of your code…

<$button popup=<<notes.popup.tiddler>> tooltip="view/edit.notes for this tiddler" tag=div>
<%if [<notes.popup.tiddler>has[title]] %>
   <button>View Notes</button>
<%else%>
   <button>Edit Notes</button>
<%endif%>
</$button>

Is there a reason why you’re using HTML buttons inside a $button widget with the <div> tag? IMO, it’d be easier and more semantic to make a single button with variable content. I might do something like this:

\function button.label() [<notes.popup.tiddler>has[title]then[View]] ~Edit

<$button popup=<<notes.popup.tiddler>> tooltip="view/edit.notes for this tiddler">
	<<button.label>> Notes
</$button>
#10

It was just to illustrate an idea, that <button>name</button> only generates a look alike button.

  • The div was just to hide the proper button, if not used this method would look like this;
    2025-11-05_16-25-04

If you look closer, this is one button widget that displays according to the state of the popup, which is the existence of a temp field. Notice how the button does nothing else at all?

  • I believe this may be the easiest way to toggle a condition.

I was not planning to create a “canonical solution” but something to talk about and share comments on the code used. However perhaps this is not the best way to demonstrate the uses of a simple html button <button>name</button> because of the ambiguity and a standard way will suffice.

it now reads without the tag-div and

<%if [<notes.popup.tiddler>has[title]] %>
   View Notes
<%else%>
   Edit Notes
<%endif%>

The other tag div was to introduce other class/styles but I will remove that too.

Final result? possibly not, its designed to be talked about

\procedure view/edit-notes()
   \function notes.popup.tiddler() [<qualify $:/temp/edit-notes>]
   \define note.database() $:/note.database
   <$button popup=<<notes.popup.tiddler>> tooltip="view/edit.notes for this tiddler">
      <%if [<notes.popup.tiddler>has[title]] %>View Notes<%else%>Edit Notes<%endif%>
   </$button>
   <%if [<notes.popup.tiddler>has[title]] %>
      <$edit tiddler=<<note.database>> index=<<currentTiddler>> class="tc-edit-texteditor tc-popup-handle" />
   <% elseif [<note.database>getindex<currentTiddler>!is[blank]] %>
      <fieldset style="padding: .5em; "><$transclude tiddler=<<note.database>> index=<<currentTiddler>> mode="block" /></fieldset>
   <%endif%>
\end view/edit-notes

<<view/edit-notes>>

Thanks for highlighting this was obscure.

#11

Yes, I followed that. I was just trying to figure out why you’d want to make a button, hide it, and then fill it with pseudo-button(s).

#12

Just to show something which I subsequently did not do. Build more inside the popup button. I think it is better to demonstrate the minimalist toggle example. It can be used for many things and be present anywhere you can place it with the content it unfolds also places where you want.

  • It could trigger an action, delete an entry by responding to the modifier keys, that may be a good way to demonstrate %if used like a case statement.

If you can see a way to include any other smarts without complicating it too much let me know.

#13

I think it’s very reasonable to use it for conditional content display, since that’s more or less what popup is designed to do. I’ve always used it with $reveal, myself, as suggested by the docs, but it’s nice to see that it can be used with <%if%> as well in situations where you don’t want an actual popup.

Could you expand a little more on that? I’m having trouble envisioning how action widgets could be triggered by the popup attribute alone, or how this would be more efficient than simply using a standard actions attribute. I suppose you could include a conditional that referenced the current popup state in an actions string or procedure…?

Generally, though, I’d be wary of tying action execution to something as transient as a popup. Eric’s solution is perfect for conditional display if the only thing you want to do is toggle the textarea — and I could see this being very useful for inline field editing, for instance. But even with the tc-popup-handle class in place, clicking anywhere else on the page will still delete the state tiddler; it’d be easy to do so entirely by accident. So I think you wouldn’t want to attach any actions that couldn’t be easily reversed — and you’d want to be very careful to ensure that they wouldn’t be triggered inadvertantly.

#14

No, same as you, I would be using the actions parameter on the button using the popup. The main idea was inside an action procedure, using %if nested to be a case statement to handle different modifier keys. This is just a demo to start a conversation.

#15

well i tested it! , ( nice idea btw ),
and tried to read through and understand what dose what
and my internal parser failed/bailed at line one
with error :WTF

\function notes.popup.tiddler() [<qualify $:/temp/edit-notes>]

im flummoxed by this filter ? operator ??? [<var>]

<qualify $:/temp/edit-notes>

or is it a macro with an unquoted argument
in a filter ?
( if so no tw5-com docs examples i could find with this syntax seamed to exists)

** fly’s into the air and
disappears into the the gorge of <eternal ?> {!!syntactic} $peril

#16

You can wait until the official annotated release but consider this “exhibition code” intended to be read and cause questions.

Got Ya! :clap:

We can include variables and macros/procedures in filters. Of course their output needs to be suitable for what comes next in the filter. This example is using the qualify macro to generate a title and does exactly that.

  • It shows how macros/procedures/functions and variables are all a different side of the same coin.
#17

They should be on the same line

#18

( eddied it )
small screens :face_with_symbols_over_mouth: :grimacing:

my tw comprehension/frustration
might be directly correlated to screen size
tbh

#19

I do like the idea and the code is compact but imo very hard to extend.

I personally would want much more flexibility for every element.

  • Button and button-actions
    • eg: OK and Cancel … (todo)
    • Cancel should restore the “old” note (todo)
  • The button may have images instead of text (todo)
  • The button may be somewhere else in the UI
  • The note itself
    • styling using classes
  • Keyboard shortcuts
    • eg: CTRL-Enter in the note saves the note (todo)

… and so on

I did separate the different areas into their own procedures, to be able to implement the above ideas more easily.

The following tiddler is a TestCase tiddler

have fun!

toggle-note-testcase.json (1.5 KB)

title: toggle-note-testcase
tags: $:/tags/wiki-test-spec
type: text/vnd.tiddlywiki-multiple
description: Toggle Note Input

with the following content

title: Narrative

* Show an Edit Notes / View Notes toggle button
* Notes are written to a $:/note.database tiddler

+
title: Output

\whitespace trim

\define note-database() $:/note.database
\function state() [<qualify $:/temp/edit-notes>]

\procedure toggle-actions()
<%if [<state>is[tiddler]]%>
  <$action-deletetiddler $tiddler=<<state>>/>
<%else%>
  <$action-setfield $tiddler=<<state>> text=edit/>
<%endif%>
\end

\procedure toggle-button()
<$button actions=<<toggle-actions>> tooltip="view/edit notes for this tiddler">
  <%if [<state>is[tiddler]] %>
    View Notes
  <%else%>
    Edit Notes
  <%endif%>
</$button>
\end

\procedure note()
<<toggle-button>>
<%if [<state>is[tiddler]] %>
  <$edit tiddler=<<note-database>> focus=yesX index=<<currentTiddler>> class="tc-edit-texteditor c-edit" />
<% else%>
  <fieldset class="c-note">
    <$transclude tiddler=<<note-database>> index=<<currentTiddler>> mode="block" />
  </fieldset>
<%endif%>
\end

<<note>>
+
title: $:/note/styles
tags: $:/tags/Stylesheet

.c-note {
  padding: 0 0.5em 0 0.5em;
}
.tc-tiddler-frame textarea.tc-edit-texteditor.c-edit {
  padding: 14px .5em;
}
+
title: $:/note.database
type: application/json

{
    "Output": "some text"
}
#20

Mario, I for shadowed the additional features but was planning to use it to describe the parts.

I will review in my morning :nerd_face:

1 Like
#21

Thanks @pmario for the ideas within your restructured code and testcase, I was however going to publish it as an exercise or guide to a number of “features” I used in my example. Rather than a complete solution, however there seems to be an interest in a fuller solution using this mechanism, for that I would implement many of your suggestions.

  • Its only weakness I can see is if the tiddler is renamed it will loose access to the note, and Relink does not yet seem to support a title used as the key to a data tiddler.
#22

Jup. I do have a similar function in my script-manager edition, which is my main wiki, that I use every day. It’s basically a “brain dump” with ToDo’s included.

It creates 1 data-tiddler per “script” tiddler. Where every “script” tiddler basically is a “dashboard” itself.

If a new “script” tiddler is created (1) it shows a (2) Created Links Container, for that tiddler. But only the tag matters. So relink can change the tag if the script-title is changed.

image
image1890×404 30.8 KB

The functionality there is not exactly the same as you described, but the whole thing has several step by step videos. — which are quite old (2017) now. But the workflow is the same today as it was then.

The TW code is also from 2017 so it can not be used to demonstrate latest wikitext. I did record some “update” videos, but Youtube got the subtitles completely wrong :confused: (they are not public atm)

#23

I wonder if because relink is so good at what it does we have not explored other opportunities that may help in circumstances like this?

Just before RELINK was made I was asking for a hackable mechanism on rename. The idea would be when saving a tiddler, with a changed title, it would trigger actions on rename found in tiddlers tagged $:/tags/action-on-rename. It would provide old and new names and we can write an action that renamed the key to the note in the data tiddler.

  • Of course this does not capture other forms of rename.
  • What ever updates the modified times stamp, may also be an opportunity to trigger “on modification actions” that designers could add custom actions built into TiddlyWiki scripts, via a system tag, all we need to do is ensure the old and new title is available.
  • If as has being rumoured relink may move to the core, this would be a feature to add if not the actual rename of data tiddler keys that are also titles.
#24

I do not think so. Relink is a huge project on its own and not everyone needs all the possibilities if offers. But I think, we could make the core relinking a bit more intelligent since https://github.com/TiddlyWiki/TiddlyWiki5/pull/8258 is now merged. So the core can now “rebuild” simple wikitext and there should be enough info to handle simple transclusions and links in wikitext.

Tags and list-fields are also updated from the core. So no relink needed.

#25

Sorry but I tried to follow but cant. I do see reference to the undesirable <p></p> tags the transclude index returns, but is this also relevant to rename?

#26

I have written my

Exposé of various methods - Notes on tiddlers stored in a data tiddler

Shall I post it here for peer review, or just publish?

#27

You can publish it under Tips & Tricks. You may make it a wiki. So everyone can improve it.

To change something in wikitext, you need to exactly know where eg: a transclusion starts and ends. Since parsing is expensive and slow for a huge amount of tiddlers, we use the tiddler parse-tree cache for this. The core had start / end info for quite some time, but the API functions to convert a parse-tree back to wikitext was missing. The linked PR has these functions now.

Relink still does much more, but having the basics in the core can help everyone.

#28

Now Published Tips and commentary - Notes on tiddlers stored in a data tiddler

1 Like