Is there a way to set columns in a @Mohammad’s Shiraz dynamic table to show different checkboxes activating tags to show like an array of checkboxes to set different tags on tiddlers ?
Do you mean a column header with a checkbox, on click add/remove a specified tag to all records (tiddlers)? If so, the current implementation add/remove done tag, so you can clone the template and change as you like.
Well, Shiraz Dynamic Table has not such template. By the way you can write a template yourself. So, it is possible.
Ok. I think this may be beyond my TW coding abilities; but I will try.
Thank you anyway for your great plugins so well documented and engineered.
I’m not sure how to do this in Shiraz, which really wants columns to be fields.
But in plain TW, it’s surprisingly easy, as the checkbox widget has special handling for tags.
<$let tags="Foo Bar Baz Qux Corge" >
<table>
<tr><th>Title</th><$list filter="[enlist<tags>]"><th><$link/></th></$list></tr>
<$list filter="[tag[MyGroup]]" variable="tiddler">
<tr>
<td><$link to=<<tiddler>> /></td>
<$list filter="[enlist<tags>]" variable="tag">
<td><$checkbox tiddler=<<tiddler>> tag=<<tag>> /></td>
</$list>
</tr>
</$list>
</table>
</$let>
And if you want to derive the list of tags, something like this should do, although I suspect there’s something simpler that I haven’t been able to come up with:
<$let tags={{{ [tag[MyGroup]tags[]unique[]format:titlelist[]] -[[MyGroup]] +[join[ ]] }}}>
Edit: not simpler, but perhaps slightly more robust (would handle spaces in the group name):
<$let tags={{{ [tag[MyGroup]tags[]unique[]] -[[MyGroup]] :map[format:titlelist[]] +[join[ ]] }}}>
You can try this by downloading the following and dragging the resulting file on any wiki: TagTable.json (7.0 KB)
1 Like
That’s true. The columns are fields (or indexes) and it is not possible to implement such functionality as requested in the OP, but you can trick Shiraz Dynamic Table in this way:
Shiraz looks for a template to show column contents. When you pass tag1 as a field, Shiraz looks in Dynamic Table templates, and searches in their list field called: tbl-column-list. A template for tag1 has tag1 in its tbl-column-list. You can then add your own calculations, actions, etc. in this template and Shiraz will render the results.
Example
Here is an example implements the main OP
title: what you like
tag: $:/tags/Table/BodyTemplate
body (text):
<td><$checkbox tiddler=<<currentRecord>> tag=<<currentColumn>> /></td>
tbl-column-list: tag1 tag2
Code and demo
-
Download shiraz-dtable-applytags-template-with-examples.json (634 Bytes)
-
Then drag it and drop into Shiraz 2.9.7 — create stylish contents in Tiddlywiki
-
Open Test of myTemplate and play with example
The template is defined in mytemplate/apply-tags
1 Like
As much as I like Shiraz’s dynamic tables, I did start working on my own version because this mechanism felt too constricting. I may never complete it, since Shiraz was plenty for the need of the small wiki I used it on, and that was my very first requirement for sortable tables.
The problem is that in different tables, I might want distinct formatting for fields. It’s not just that the same field name might be reused in ways in different groups of tiddlers, although that is a real concern (think of total being an integer count one place and a currency amount in another.) It’s also that different views of the same data might take different formatting, and some columns, as you demonstrate above, might be synthesized from several fields, or take only part of a single one.
For instance, we might have this:
| first-name | last-name | dob | profile |
|---|---|---|---|
| Mike | Wheeler | 1971-04-07 | https://example.com/person/28 |
| Dustin | Henderson | 1971-05-29 | https://example.com/person/42 |
| Will | Byers | 1971-03-22 | https://example.com/person/39 |
| Lucas | Sinclair | 1971-11-15 | https://example.com/person/19 |
| Max | Mayfield | 1971-01-05 | https://example.com/person/47 |
| Eleven | Hopper | 1971-06-07 | https://example.com/person/99 |
Or this:
| Name | Birthday |
|---|---|
| Mike Wheeler | April 7 |
| Dustin Henderson | May 29 |
| Will Byers | March 22 |
| Lucas Sinclair | November 15 |
| Max Mayfield | January 5 |
| Eleven Hopper | June 7 |
based on the same data. Here the first version is a fairly literal display of four field names. But in the second one, we combine three of the fields into a single column and display the other one (dob) in an entirely different manner from the first table.
So while I like the simplicity of the column templates in Shiraz, I also want more flexibility. I don’t know if there is a backwardly-compatible way to deal with this in Shiraz. One problem is that both tables use the dob field directly, with different displays. The other problem is that the second table synthesizes its first column from three different fields. For both of these issues, the tbl-column-list mechanism is simply not enough.
But I’m not really sure how to do this well in TW, either. In plain JS, to describe the columns, I would use a configuration object like this:
[
{title: 'first-name', display: '$:/.../string', sort: 'sort', fields: ['first-name']},
{title: 'last-name', display: '$:/.../string', sort: 'sort', fields: ['last-name']},
{title: 'dob', display: '$:/.../string', sort: 'sort', fields: ['dob']},
{title: 'profile', display: '$:/.../url', sort: 'sort', fields: ['profile']},
]
and
[
{title: 'Name', display: '$:/.../name-link', sort: 'sort', fields: ['first-name', 'last-name', 'profile']},
{title: 'Birthday', display: '$:/.../birthday', sort: 'month-day', fields: ['dob'] },
]
where sort could take other values such as ‘number’, and where the display and sort properties would be defaulted to the values in the first sample above, and fields would default to an array containing just the title, leaving the first sample as only:
[{title: 'first-name'}, {title: 'last-name'}, {title: 'dob'}, {title: 'profile'}]
But again, I’m really not sure how to do an equivalent in wikitext.
@Mohammad, is this at all a direction in which you could see Shiraz tables expanding?
Hi @Scott_Sauyet,
It would be great to see your own version of sortable, dynamic tables. In Shiraz, the main concept behind dynamic tables is to generate rows from tiddlers and columns from fields. In the base version, only the field values are displayed as raw text. The template then determines how to render the field content in various ways. Therefore, different templates may be required for different forms of displaying field contents.
One issue is that all of these templates need to be hard-coded. For example, a template with ‘birthday’ in ‘tbl-column-list’ may read from two fields and display something synthesized from them. The challenge here is sorting the table when a column is based on several fields, which is possible but requires more complex code.
Yes, that clearly is the hard part. And I punted on that by only displaying configuration. I would expect the sort property to point to something that could be used in sortsub or someplace similar, although I haven’t dug into it carefully. For instance, a full-name sorter might look like this:
\procedure by-full-name() [{!!last-name}] [{!!first-name}] +[join[, ]] +[lowercase[]]
and I might use it like this:
<<list-links filter:"[tag[Person]!sortsub:string<by-full-name>]" >>
Just so you know, this was not the impetus for my looking at my own version. Instead, I wanted to be able to sort on multiple fields, first sort by highest → lowest priority, and then by date, descending. But as far as I went was the logic to use clicks on the headers to set a field with the list of sorts applied:
| click-action |
sort-by field |
|---|---|
| (initial) | (none) |
| title | title |
| date | title date |
| date | title !date |
| title | !date title |
| date | title date |
| date | title !date |
| priority | title !date priority |
I don’t know if I even saved that code, but I was going to use that sort-by field to change the sorting on these clicks. In that final step, the sort would look like
[my[filter]sort[title]!sort[date]sort[priority]]
Looking at it again today, a few days later, and I realize that I should probably have three states for each field, so a field starts in don’t-sort, goes to sort-ascending on a click, goes to sort-descending on a second, then back to don’t-sort on a third, and it would simply be removed from the list of sort-fields.
That, if completed, might be a useful extension to the technique linked to in the Thanks for Shiraz thread. But when I realized that I might also want numeric sorting, or multi-field presentation, I spent a few minutes contemplating it, and put it aside. Perhaps I will look again in the next few days.
Great ideas! I would be happy to see your solution.