Dictionary Table

[vilc]

The Dictionary Table plugin makes dictionary tiddlers displayed as a table, sorted alphabetically by key. Clicking a key or value will copy it to clipboard.

Vanilla palette dictionary tiddler without the plugin:

With the plugin:

• Alignment in a table makes dictionaries much more readable.
• Data displayed sorted alphabetically, even if raw content is unsorted – might also be seen as a disadvantage. I don’t know any way to retrieve dictionary’s content “as is”, since TW sees it as a JSON object, which doesn’t have predictable sorting.
• Applied only to dictionary tiddlers, not to JSON tiddlers. I’ve found no easy way to determine if a JSON tiddler is a simple, one-level object of name-value pairs (in which case it makes sense to display it as a table) or a multi-level nested object (in which case the table makes no sense).

[vilc]

@etardiff’s post from the plugin library thread:

@etardiff

Thank you for sharing! I love the dictionary tiddler table; it makes things much more readable.

I felt a little guilty since your code is so elegant, but I tweaked the table template a bit for my own use and thought I’d share back in case anyone else is interested. The code below replaces $:/plugins/wilk/dictionary-table/template; it enables double-clicking on a value cell to edit it inline, enter to save back to the data tiddler, and esc to exit edit-mode without saving changes.

\procedure display(content)
<$button
	class="tc-btn-invisible"
	message="tm-copy-to-clipboard"
	param=<<content>>
	tooltip="Copy" >
		<$text text=<<content>> />
		{{$:/core/images/copy-clipboard|1em}}
</$button>
\end

\procedure edit() <$action-createtiddler $basetitle=<<dom-temp>> />
\procedure cancel() <$action-deletetiddler $tiddler=<<temp>> />
\procedure save()
<$action-setfield $tiddler=<<currentTiddler>> $index=<<index>> $value={{{ [<temp>get[text]] ~[<value>] }}} />
<<cancel>>
\end

<$eventcatcher selector=".index" $dblclick=<<edit>> tag="div">
<table class="wilk-dictionary-table">
<$list filter="[<currentTiddler>indexes[]sort[]]" variable="index">
	<tr>
		<td>
			<$transclude $variable="display" content=<<index>> />
		</td>
		<$let
			temp=`$:/temp/volatile/$(currentTiddler)$/$(index)$`
			value={{{ [<currentTiddler>getindex<index>] }}}
		>
		<td class="index" temp=<<temp>>>
			<% if [<temp>is[tiddler]] %>
				<$keyboard key="enter" actions=<<save>>>
				<$keyboard key="escape" actions=<<cancel>>>
					<$edit-text tiddler=<<temp>> tag=input class="tc-max-width" default=<<value>> />
				</$keyboard>
				</$keyboard>
			<% else %>
				<$transclude $variable="display" content=<<value>> />
			<% endif %>
		</td>
		</$let>
	</tr>
</$list>
</table>
</$eventcatcher>

---

@etardiff this is a very interesting modification, thank you! I would have to think if I need it, but it seems a very logical extension of my initial idea. Two UX details that would make it even better:

• Not copying the value on the fist click of the two clicks to edit, in case user wants to paste a previously copied content into the edited cell. This seem difficult with the current design, there would probably have to be a second button to explicitly edit.
• Click outside of the edited field also exits edit mode, just as Esc.

Just thinking loud. I’m not entirely sure that these are good ideas or worth implementing. The beauty of the plugin and your modification is that they are very simple and lightweight.

[etardiff]

@vilc

Not copying the value on the fist click of the two clicks to edit, in case user wants to paste a previously copied content into the edited cell. This seem difficult with the current design, there would probably have to be a second button to explicitly edit.

I thought about this too, but I liked your click-to-copy and didn’t want to lose any existing functionality. I did actually consider an extra button, but decided against it as it would have required some CSS modifications as well.

@vilc

Click outside of the edited field also exits edit mode, just as Esc.

This is an interesting idea, though it would eliminate a current workaround to issue #1: at present, you can double-click a cell to edit, then single-click a different cell to copy the value. That might be a reasonable tradeoff for some people, though… in which case, you could probably modify the copy-to-clipboard button to delete any tiddlers with the $:/temp/volatile/$(currentTiddler)$ prefix. My display procedure is only rendered for cells that aren’t in “edit mode”, so you could safely click inside the $edit-text without cancelling the edit.

I’m not sure how practical it would be to catch clicks outside the table, though. You could add an $eventcatcher inside the body of the tiddler, but to catch clicks in the tiddler margins or the sidebar, etc., I think you’d need to modify the page template.

I’d love to hear any thoughts on this, though. Thank you again for the clever solution and the inspiration!

[TW_Tones]

Can someone share, if possible, the modified version with @etardiff’s last recommended improvements for “drive by collectors”, wanting this solution please.

[etardiff]

I don’t want to repackage @vilc’s work without his permission, but here’s a package with my modifications, to be used in conjunction with his plugin: Dictionary Table modifications.json (2.8 KB)

The actual template changes are discussed in the post of mine quoted above. I’ve also made some very minor CSS modifications and expanded the cascade config filter to include application/json tiddlers without the plugin-type field.

[vilc]

@etardiff and everyone feel free to modify or repackage it, as per the MIT license that I’ve given this plugin.

Since this seems to be popular, maybe I could keep a packaged alternative variant of this plugin with @etardiff’s modifications in my library (with you permission and credit to your work of course)? This way it will be easier to find and use.

[etardiff]

Feel free! One of the reasons I’m always hesitant to share repackaged plugins (even if the license permits it) is that it creates potential confusion about where to find a particular version or who’s responsible for maintaining it. If you’d like to share it alongside your original, I think that would be ideal.

[vilc]

So here we have the Dictionary Table (editable) variant in my plugin library, with @etardiff’s modifications allowing to quickly edit the values.

I hope this will be of help. If find the time I’ll think about merging the two variants:

• the editing doesn’t take anything away from the way I made the plugin (just adds a tiny amount of unnecessary code)
• it seems to work well with “simple” JSON tiddlers, but is expectably incompatible with “complex” JSON tiddlers, e.g.:
  
  
  becomes
  I would ideally like the plugin not to break anything.

Does anyone have an idea for a filter (for the rule) that would check whether a JSON tiddler is a “simple” (only one level of key value pairs) or a “complex” one (like on the screenshot above)?

[vilc]

[{json}jsonindexes[]] :map[{json}jsonindexes<currentTiddler>]

Am I correct to think that this filter will return something for a complex JSON tiddler titled “json”, and nothing for a simple JSON tiddler? The logic is to check whether any of the top level indexes contains any deeper level indexes. This would be some point to start. I would have to check how it behaves if the JSON contains arrays for example.

[jacng]

I make a quick attempt to try to determine the number of levels (below), but not entirely sure if my curly logic make sense for all cases. Hopefully, this can be helpful to build complex table.
No, that doesn’t work on second thought.

Could be useful for checking for more than 1 level though, which was where I started of.

Let me come back to that.

Nope, I wasn’t able to find an easy incriminating { within the JSON tiddler that points to a second level.

You are on the right track. This shows the JSON type of all first level elements for object type which is use to define a second level.

<$let dict={{{[[data tiddler]get[text]]}}}>
    <$list filter="[<dict>jsonindexes[]]" variable=element >
          <<element>> : {{{[<dict>jsontype<element>]}}} <br>
    </$list>
</$let>

Or similar to what you wrote:

<$let dict={{{[[data tiddler]get[text]]}}}>
{{{[<dict>jsonindexes[]] :map[<dict>jsontype<currentTiddler>match[object]else[]] }}}
</$let>

[TiddlyTitch]

@vilc

So here we have the Dictionary Table (editable) variant in my plugin library, with @etardiff’s modifications allowing to quickly edit the values.

Very good on you @vilc & @etardiff!

The implementation is really good!

Lightweight, works.

I’m testing it more. Will comment in a while.

TT

[TiddlyTitch]

@vilc

here we have the Dictionary Table (editable) variant in my plugin library,

I have three comments …

1. Might it be a good idea to ADD column SORTING?
   A lightweight JS way would be via the well-used “sortable” from: GitHub - tofsjonas/sortable: Vanilla JavaScript table sort

2. The editable version is great for simple tables. It really makes life easier. With complex tables (i.e. wiih merged cells) I’m not so confident–but haven’t tested it much.

3. REQUEST: Could you give an option to let the user add a CSS class to a table?
   <table class="wilk-dictionary-table EXTRA-CLASS-HERE?">
   It could be useful. Especially if you need sorting that needs a class to start (point 1).

Anyway, it is all very good!
TT

[vilc]

Thanks for the comment. Interesting ideas, and surely useful to someone. But I’m afraid this is far outside of what I need or am able to put together as a plugin.

To make my initial simple idea complete, I would like figure out how to set up the rule filter, so that the plugin table will be displayed for simple JSON tiddlers only (and ignore the complex multi-level JSON tiddlers, like plugins).

[TW_Tones]

First, of course we can check the type field, but then we need to determine the JSON format in use. I too am still struggling with this and how to tell the differences. There is however a pattern of prefix and suffix of the whole text field which should be able to tell us, the format in use. It is possible to expand the format with spaces, tabs and newlines to make them more readable so perhaps we need to develop regular expression based tests;

We should be able to make a custom operator that checks in the text field has the prefix/suffix for each type and return a name representing each format. Allowing our different solutions to know how to access the different format.

Here is some prior art;

How do TWs JSON Formats Look Like

This is a response to a question. Intro This thread shows several different types of JSON structures that can be handled and imported by TiddlyWiki. Tiddler Export Format This format can be created using the toolbar button “export tiddler” → “JSON file” for a single tiddler [01-single-tiddler-export-format] File Format Exporting a Single Tiddler The content of the file looks as follows and is “machine readable”. [{"created":"20230123143053957","text":"Some text in the Hello World tiddle…

Conversion tools between the various tiddler and JSON formats

A response to this has being started by @pmario here How do TWs JSON Formats Look Like As discussed here Identify tiddlers installed by bookmarklet we have various forms of tiddler and tiddlers in a single tiddler formats and encoding, even within what we may call a JSON tiddler. We have some templates and widgets that handle some of these formats illustrated below; I would like to build a resource that documents these and the differences, such that we can document when and where they occur…

Discussion about: How do TWs JSON Formats Look Like

Thanks Mario for what I presume was in part a response to my topic Conversion tools between the various tiddler and JSON formats this is a very helpful resource. A matter arising; To assist conversions it would be helpful if we share some code to add or remove “wrappers” such as your documented [{ }] vs [ { } ] and { "tiddlers": { .... } } And/or point to the widgets that are involved. Noting that we need to be able to convert both simple and pretty forms, to an from.