Create tables with the list filter macro??

236 views
Skip to first unread message

Måns

unread,
Jan 12, 2012, 6:38:00 PM1/12/12
to TiddlyWiki
Hi TwWizards

Id like to be able to create tables with the list filter macro via the
templating feature.
How do I do it??

I know how to create templates to style tables for individual list
items:

http://tabel.tiddlyspace.gir.dk/#%5B%5BSimpel%20tabel%20via%20listfilter%20makro%5D%5D
http://csv-eksempel.tiddlyspace.gir.dk

What I want is to be able to do is to:

Define column headers and captions for whole table or each row....
(maybe even a first row to the left - (count rows or whatever) if I
want to view/present tiddler fields in cells placed vertically on top
of one another ...)
Define a footer for whole table or each row...

Has anyone had any success in creating tables with the list filter
macro??

Cheers Måns Mårtensson

PMario

unread,
Jan 13, 2012, 3:43:29 AM1/13/12
to TiddlyWiki
Hi,
I'm not exactly sure, what you try to achieve, but I can tell, what
the <<list filter >> macro does.

It creates a html structure like the following:

<ul>
<li> some wikified template text </li>
<li> some wikified template text </li>
<li> some wikified template text </li>
</ul>

So whatever you create with one iteration of the template, it will
allways be covered by <li></li>

I think, what you want is similar to
<ul>
<li> caption text </li>
<li> some wikified template text </li>
<li> some wikified template text </li>
<li> some wikified template text </li>
<li> footer text </li>
</ul>

which would need some special css class definition for the header and
the footer. So header and footer, will be "special cases" for the list
macro. So IMO, if that's what you want. It isn't possible with the
core list macro.

-m

Måns

unread,
Jan 13, 2012, 8:34:51 AM1/13/12
to TiddlyWiki
Hi Mario

> I can tell, what
> the <<list filter >> macro does.
>
> It creates a html structure like the following:
>
>  <ul>
>    <li> some wikified template text </li>
>    <li> some wikified template text </li>
>    <li> some wikified template text </li>
>  </ul>
>
> So whatever you create with one iteration of the template, it will
> allways be covered by <li></li>

Ok... - thanks.

We can't change the <ul></ul> to <table></table> and <li>s to
<tr><td></td></tr>s via some nifty CSS?
Just to get a simple table with one row??

Easiest way to template lists as a single table might be to be able
to completely override the <ul><li>s and write your own table with
simple TW table-syntax, allowing for extra columns and rows ad
libitum...

Cheers Måns Mårtensson

PMario

unread,
Jan 13, 2012, 10:47:46 AM1/13/12
to TiddlyWiki
On Jan 13, 2:34 pm, Måns <humam...@gmail.com> wrote:
> Easiest way to template lists as a single table  might be to be able
> to completely override the <ul><li>s and write your own table with
> simple TW table-syntax, allowing for extra columns and rows ad
> libitum...
hmm,
which would lead us to fET. right? :)

Måns

unread,
Jan 13, 2012, 11:40:34 AM1/13/12
to TiddlyWiki
Hi Mario

> hmm,
> which would lead us to fET. right? :)

Ha, ha ha ;-D

This would be much easier than setting up fET tables, because a row
could be designed any way you want via a template..
Example (two rows which will be interpreted as one row in a full
table):
!template
|<<view title link>><br><<edit title 1>>|<<view imagefield wikified
"[img[http://flickr.com/%0]]">>|<<toolbar deleteTiddler>><<toolbar
fields>><<tags>>|
|<<view number wikified>>|<<view address text>>|<<view phone wikified
[[<html><a href="tel:%0"> %0 :☎</a></html>]]>><br><<edit text 5>>|
!end %/

Cheers Måns Mårtensson

Message has been deleted

Tobias Beer

unread,
Jan 13, 2012, 5:16:41 PM1/13/12
to TiddlyWiki
How about wrapping it all in a css class, and then style each item as
left floating blocks, like address cards?

I know what you are going to say to that: "But I like tables ...and
besides, how could I make those address cards sortable, like
TableSortingPlugin would?".

Well, you can always go for TiddlerListMacro [1] to do what you asked
for... with group headers and footers and the whole thing outputting a
table.

Other than that, the list makro really would need to be extended
exactly the same way like TiddlerListMacro, providing header, footer
and item templates.

tb.

[1] http://sites.google.com/site/jackparke/jtw.html
Message has been deleted

Tobias Beer

unread,
Jan 13, 2012, 5:34:35 PM1/13/12
to TiddlyWiki
Not that I would terribly mind... although I do wonder how these
things ended up in facebook:
http://www.facebook.com/note.php?note_id=10150142002095640

This issue still seems to be existing, and it isn't even caused by
TiddlerListMakro. That is rather due to a bug in the core when it
comes to the tiddler macro (and/or evaluated parameters) misbehaviing
during TiddlyWiki startup.

tb.

Eric Shulman

unread,
Jan 13, 2012, 6:30:01 PM1/13/12
to TiddlyWiki
> ... a bug in the core when it
> comes to the tiddler macro (and/or evaluated parameters) misbehaviing
> during TiddlyWiki startup.

During macro handling, the TWCore invokeMacro() function calls on
parseParams() so it can populate the 'params' array that is then
passed along to the specific macro handler. It is during processing
of parseParams() that evaluated parameters (i.e., {{...jscode...}})
are invoked, and their resulting values included in the params array.

Many TWCore macros (and most plugin-defined macros) rely upon
invokeMacro() to pre-parse their params. However, some macros, such
as <<tiddler>>, also call parseParams() themselves in order to perform
more advanced parameter handling, such as extracting *named*
parameters from the raw 'paramString' that is also passed to the macro
handler.

Unfortunately, re-processing the paramString also causes any evaluated
params to be RE-invoked, resulting in the double-processing that has
been observed. Of course, if the eval param is just fetching a value
(e.g., {{tiddler.title}} or {{new Date()}}), then it usually doesn't
matter if it is processed more than once. However, if the eval param
does something visible or that has a side-effect (e.g., displaying a
message or incrementing a counter), then the extra processing will
produce unexpected interactions and/or incorrect results.

Fortunately, there *is* a configuration-based fix for it! Some time
ago (TW2.5.x), I submitted a core patch that can be used to
selectively disable the 'pre-parsing' of parameters for any given
macro by setting
config.macros.nameOfMacro.noPreParse=true;
When set, invokeMacro() skips the call to parseParams() and passes an
empty 'params' array to the macro. It is then left to the handler
itself to invoke parseParams() to process the params as needed. Thus,
because the tiddler is already doing it's parserParams() procesing,
the macro doesn't rely upon the 'params' array, and we can safely
disable the pre-parsing for that macro by setting:
config.macros.tiddler.noPreParse=true;

Note: this setting *could* be included in the TWCore by default, but
it was decided to leave the existing behavior unaffected out of an
abundance of caution about backward-compatibility. However, as far as
I can determine, there is *no* use-case for which disabling pre-
parsing for the <<tiddler>> macro would cause a problem.

enjoy,
-e

Tobias Beer

unread,
Jan 13, 2012, 8:30:27 PM1/13/12
to TiddlyWiki
Oh good, thanks Eric! Now I remember that we talked about this
solution back then when it hadn't been in place yet. I never noted
that it came. I have to admit, I don't much look at release notes nor
do much beta testing. Mhhh...

We should probably also find a good spot for that and perhaps some of
your core hacks as well in the org.

tb
Reply all
Reply to author
Forward
0 new messages