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,
Paul (psd)
--
http://blog.whatfettle.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/TiddlyWiki?hl=en
-~----------~----~----~----~------~----~------~--~---
