FatSlicePlugin

[paul.s...@gmail.com]

Phil Hawksworth and I scratched an itch and came up with
a "Fat" slice plugin.

Like the default TiddlyWiki slices the first column is an index.
Unlike the default slices, you can have multiple columns, and
access a column by name, the names coming from the title row.

This is probably best explained with an example:

in the table:

| |!column1 |!column2 |!column3 |
|row1| a | b | c |
|row2| d | e | f |
|row3| g | h | i |

in a tiddler called "Data", the macro:

<<slice [[Data]] "row1" "column2">>

returns "b".

There's a version in a TiddlyWiki to play with, here:

http://whatfettle.com/2008/07/FatSlicePlugin/

You can get the latest version from subversion:

http://svn.tiddlywiki.org/Trunk/contributors/PaulDowney/plugins/FatSlicePlugin/
http://is.gd/4uHy

and via http://plugins.tiddlywiki.org
(sadly no permalink!)

I dare say there are other ways of accessing the
wide values, via the tiddler macro and view templates,
and we could consider wikifying the values into plain text,
but for now, it is what it is.

Enjoy!
Paul (psd)
--
http://blog.whatfettle.com

[Dave Gifford - http://www.giffmex.org/]

Holy cow, creating a table and then a slice macro is so much easier
than typing 'b'! Great job!

Seriously, though, it looks interesting and helpful, but maybe you can
help my dim imagination - it has been a long day - what are some of
the helpful uses for this that you can envision?

Dave

[Ken Girard]

You have a master table in the OreoTable tiddler which tracks who ate
Oreos on which day of this month, and references to various different
cells in it scatter here and there.
When you update the table next month, you also update all the
references.

Ken Girard

On Oct 21, 9:16 pm, "Dave Gifford - http://www.giffmex.org/"

[Eric Shulman]

> Like the default TiddlyWiki slices the first column is an index.
> Unlike the default slices, you can have multiple columns, and
> access a column by name, the names coming from the title row.

> | |!column1 |!column2 |!column3 |
> |row1| a | b | c |
> |row2| d | e | f |
> |row3| g | h | i |

>     <<slice [[Data]] "row1" "column2">>
> returns "b".

> I dare say there are other ways of accessing the
> wide values, via the tiddler macro

I like the notion of a 2D 'slice array', addressable by row and column
names... and I especially like that fact that the additional table
syntax doesn't interfere with the TW standard slice table handling,
e.g., using the above table, you could still retrieve values where
TiddlerName::row1="a", TiddlerName::row2="d", TiddlerName::row3="g",
etc.

However, I think that rather than defining a new <<slice>> macro to
access the 'fat' slices (i.e., the extra columns in each row), a more
transparent way to achieve this would be to enhance the
store.getTiddlerText() function so that it would be able to recognize
an extended syntax for specifying a slice *column name* in addition to
a *row name* (which is currently supported by the
"TiddlerName::slicename" syntax)

I'm thinking something like this might work:
TiddlerName::SliceRowName(SliceColumnName)
where the "(SliceColumnName)" portion is optional. If no column name
is specified, the standard handling (i.e., returning the value from
the first column) would be applied.

For example, given this slice array:
[[FavoritesThings]]
| |!Color|!Fruit|!Drink|
|Jim|red|watermelon|tomato juice|
|Jane|blue|berries|koolaid|
|Stanley|orange|apples|coffee|
|Edith|green|kiwi|lemon grass tea|
You could then write things like:
<<tiddler [[FavoriteThings::Jim(Color)]]>>
<<tiddler [[FavoriteThings::Edith(Fruit)]]>>
<<tiddler [[FavoriteThings::Stanley(Drink)]]>>
to display "red", "kiwi", and "coffee" respectively.

One really big advantage of extending the getTiddlerText() function is
that every plugin and core macro handler that uses getTiddlerText() to
access slices will immediately have the ability to reference values
stored in "row(column)" slice arrays as well, without needing any code
changes in those plugins or core functions!

thoughts?

-e

[PhilHawksworth]

Eric,

Yes. At the time we implemented this we didn't appreciate that we
could retrieve the values using the <<tiddler>> macro (*blush*)
We plan to implement almost exactly what you proposed although we had
been leaning towards the following syntax:

<<tiddler TiddlerName::SliceName::SliceField>>

We'll have a chat about the syntax to adopt and then evolve the plugin
accordingly.

Thanks to all for the feedback.
Phil

[Eric Shulman]

> We plan to implement almost exactly what you proposed although we had
> been leaning towards the following syntax:
>
> <<tiddler TiddlerName::SliceName::SliceField>>

Using the "::" separator twice in the section reference could be very
problematic... especially for code that currently assumes that only
one separator will be present.

For example:
var parts=split(title,config.textPrimitives.sliceSeparator);
var slice=parts[1];
var title=parts[0];
or this
var pos=title.indexOf(config.textPrimitives.sliceSeparator)
var slice=title.substr(pos+1);
var title=title.substr(0,pos);

In the first case, the slice value would be "slicename"
In the second case, the slice value would be "slicename::slicefield"

By using a different delimiter (such as parens) to identify the
slicefield, it eliminates any possible ambiguities when parsing a
"tiddler::slice(field)" reference.

-e

[paul.s...@gmail.com]

Hey Eric (et al!)

> I like the notion of a 2D 'slice array', addressable by row and column
> names... and I especially like that fact that the additional table
> syntax doesn't interfere with the TW standard slice table handling,
> e.g., using the above table, you could still retrieve values where
> TiddlerName::row1="a", TiddlerName::row2="d", TiddlerName::row3="g",
> etc.

Actually fallback wasn't a design point for us, we have a very
strong, simple use-case, a human readable data model to drive forms
entry,
more on that soon, but backwards compatibility does appear to have
fallen out in the wash.

> However, I think that rather than defining a new <<slice>> macro to
> access the 'fat' slices (i.e., the extra columns in each row), a more
> transparent way to achieve this would be to enhance the
> store.getTiddlerText() function so that it would be able to recognize
> an extended syntax for specifying a slice *column name* in addition to
> a *row name* (which is currently supported by the
> "TiddlerName::slicename" syntax)

yup! we discussed this a little with FND and Martin, and were
scared off by the risks of breaking existing interactions.

Initially Phil wanted to extend the wikifier, following on from the
way slices are referred to in a style sheet, e.g.:

div.header { background-color:[[RippleRapColors::Dark]];}

so the [[Tiddler::Row]] could be extended to [[Tiddler::Row::Col]]
unfortunately this seems to be stylesheet specific, and so for
expediency
we went for a slice macro. This has the advantage of being explicit.

I guess I'd be happy to change the functionality of existing functions
once we've a stronger idea of the usefulness (or not) of the data
model, and how it interacts with the wikifier. Experiments with
the PeriodicTable example haven't been totally successful, but
it looks very hopeful for our own purposes.

> I'm thinking something like this might work:
>    TiddlerName::SliceRowName(SliceColumnName)
> where the "(SliceColumnName)" portion is optional.  If no column name
> is specified, the standard handling (i.e., returning the value from
> the first column) would be applied.
>
> For example, given this slice array:
>    [[FavoritesThings]]
>    | |!Color|!Fruit|!Drink|
>    |Jim|red|watermelon|tomato juice|
>    |Jane|blue|berries|koolaid|
>    |Stanley|orange|apples|coffee|
>    |Edith|green|kiwi|lemon grass tea|
> You could then write things like:
>    <<tiddler [[FavoriteThings::Jim(Color)]]>>
>    <<tiddler [[FavoriteThings::Edith(Fruit)]]>>
>    <<tiddler [[FavoriteThings::Stanley(Drink)]]>>
> to display "red", "kiwi", and "coffee" respectively.

ah, that does sound like a different syntax for Phil's idea.

> One really big advantage of extending the getTiddlerText() function is
> that every plugin and core macro handler that uses getTiddlerText() to
> access slices will immediately have the ability to reference values
> stored in "row(column)" slice arrays as well, without needing any code
> changes in those plugins or core functions!

right. Thanks for the steer towards getTiddlerText (and by implication
the
<<tiddler>> macro?) I think I slightly prefer the Tiddler::row::column
syntax,
but, we should definitely consider how to better fit this into the
existing
TiddlyWiki slice apparatus, once we've proved the model has value ..

Best,

[Lyall]

Sounds like a nicer implementation of my ImprovedSlicesPlugin

See http://www.remotely-helpful.com/TiddlyWiki/ImprovedSlicesPlugin.html#ImprovedSlicesPlugin

...Lyall

On Oct 22, 3:13 am, "paul.dow...@whatfettle.com"

<paul.s.dow...@gmail.com> wrote:
> Phil Hawksworth and I scratched an itch and came up with
> a "Fat" slice plugin.
>
> Like the default TiddlyWiki slices the first column is an index.
> Unlike the default slices, you can have multiple columns, and
> access a column by name, the names coming from the title row.
>
> This is probably best explained with an example:
>
> in the table:
>
> | |!column1 |!column2 |!column3 |
> |row1| a | b | c |
> |row2| d | e | f |
> |row3| g | h | i |
>
> in a tiddler called "Data", the macro:
>
>     <<slice [[Data]] "row1" "column2">>
>
> returns "b".
>
> There's a version in a TiddlyWiki to play with, here:
>
>    http://whatfettle.com/2008/07/FatSlicePlugin/
>
> You can get the latest version from subversion:
>

>    http://svn.tiddlywiki.org/Trunk/contributors/PaulDowney/plugins/FatSl...
>    http://is.gd/4uHy
>
> and viahttp://plugins.tiddlywiki.org