This will allow creation of tables using wiki text instead of html tags or any other case where it’s important not to have a break before the header / footer (e.g. creating text that is enclosed in ```)
look closer, you could just have a header proceed the list widget and footer follow it but you can also trigger a header and footer inside the list widget. see tiddlywiki.com counter argument -first and -last. also by naming the counter you could throw a header when the counter is divisible by a number such as 20.
however if you are constructing a table from html with one or more list widgets within eg rows and columns there are html table methods that can be used instead, see a good html table reference for that method.
I think if i have a header and a footer outside of the widget they will be rendered separately, so can’t generate a wiki text table this way. And counter-first and counter-last require some sort of ‘if’
It’s not possible to easily create a wikitext table syntax using a list widget. It would need 2 full rendering steps.
- First the list would need to create proper wikitext syntax
- Then this output will need to be parsed again to create the table
Adding a header and footer parameter to the list-widget would not solve the problem. Creating a table is a very specific use-case and does not belong “inside” the list-widget.
TW widgets are designed to be generic, so user specific usecases can be solved using macros and procedures. So the list-widget can be used to solve that problem. Sadly, the solution requires HTML table syntax, which is complex in itself, but gives users all the possibilities.
An example with an early “Eierlegende Wollmilchsau” (do-everything wonder beast) widget, is the button-widget. It has so many parameters and the code is complex, for something that should be simple and light weight.
If we would have extended it with more specific use cases we would have needed to included all the action-widgets, and all the *catcher-widgets and it still would have not been good enough.
But separating those possibilities gives us the power we need with much simpler but more versatile widgets. At the cost of moving work to plugin authors …
Hope that makes sense.
-Mario
It does depend on how you are rendering your table. There are many but my preference is the html table tags and I don’t see the limitations @pmario speaks of. I will see If I can locate one of my examples. One reason html tables is great in my view is example tables abound all over the internet and LLM’s can generate the code at least for a static table, but then you can provision the rows and or columns using the list widget.
Here is an untested example, although very similar to what I have done in the past, and without the row/column filters specified.
\define rowFilter() [<!-- row filter here -->]
\define colFilter() [<!-- column filter here -->]
<table class="my-table">
<thead>
<tr>
<th> </th>
<$list filter=<<colFilter>> variable="col">
<th><$text text=<<col>>/></th>
</$list>
</tr>
</thead>
<tbody>
<$list filter=<<rowFilter>> variable="row">
<tr>
<th><$text text=<<row>>/></th>
<$list filter=<<colFilter>> variable="col">
<td>
Retrieve values and display here for each cell
</td>
</$list>
</tr>
</$list>
</tbody>
</table>
Of course I could use the LLM to place named classes on all tags, include a columns footer etc… Once the able is generated one can use CSS to add “table breaks” and repeat the header and a lot more like overflow down or left/right.