[tw] Re: [TW5] RenderTable Plugin Release
Joshua,
That is a very comprehensive nuts and bolts explanation which will help
using this powerful tool. Thank you.
I am looking forward to some use cases, but can I ask the following?
Let us put our software engineering hats to the side, and put on our
business analyst hats. *Just at a high level,* as if you were explaining in
the office.
How to you prepare data and schema to bring data into tiddlywiki in
addition to using existing tiddlers?
What is the work flow you would use to turn it into a power table?
What is your preferred data import mechanism when that data is destined for
these tables
Thanks
tony
On Tuesday, November 21, 2017 at 4:37:15 AM UTC+11, Joshua Fontany wrote:
>
> Hi TonyM,
>
> Thanks! Great feedback and questions. This will help improve the plugin's
> documentation.
>
> Before touching on Sort and Filter I'll explain the parameters of the
> widget.
>
> So <> calls <$rendertable
> schema="$schema$" mode="$mode$" datafilter="$datafilter$"
> datapath="$datapath$" tablestate="$tablestate$" />
>
> The last 2 are optional parameters:
>
>- $tablestate$ is automatically generated by the widget if blank with
>a <> macro, the input is just there for future code so this can
> be
>ignored for now.
>- $datapath$ is only used if $mode$ is set to "array".
>
> Which brings us to the core of the widget.
>
>- $schema$ must be a JSON tiddler structured as I explain in the
>example Wiki:
>https://joshuafontany.github.io/TW5-RenderTablePlugin/#Table%20Schemas
> - This is a "flat" Json Object (see my JsonMangler plugin here:
> https://joshuafontany.github.io/TW5-JsonManglerPlugin/), which just
> means there are no nested objects and the keys of the object are setup
> as
> "paths" to function as nested objects when required ("dot notation"
> like
> many libraries use).
>- $datafilter$ is a regular Tiddlywiki Filter (meaning anything from a
>single [[Tiddler Title]] to a complex set of filter chains) which defines
>the tiddlers that will make up the total dataset of the table.
> - The results of this depend on the next few parameters, but if
> left blank if defaults back to the Schema Json Tiddler (i.e. you are
> using
> the schema tiddler to also store data, see $datapath$ below)
>- $mode$ is set to wither "tiddler" or "array".
> - In both modes, the widget will detect if the current
> <> is a regular tiddler or data tiddler and adjust the data
> calls to either "fields" or "indexes" of that tiddler.
> - In tiddler mode, the assumption is that each row will be a
> Tiddler in the wikistore. Each tiddler from the $datafilter$ becomes a
> <> variable, and then the column("field") definitions from
> the
> Schema are applied:
> - either the field name defined in the schema for the current
> column is used as a tiddler field/index name(i.e.
> <>!!<> or <>##<>) and
> that is
> transcluded into the current cell,
> - or, if a template is defined in the schema, which is a tiddler
> that defines a <> macro (a macro so you can access all
> the
> various variables in the current table), it is transcluded into the
> current
> cell.
> - In array mode, the assumption is that a "row" is a collection of
> fields/indexes on a tiddler and any tiddler in the $datafilter$ can
> hold
> more than one row.
> - Each "row" would be a "flattened path" (again, see the
> JsonMangler Plugin).
> - fields: <>!!data-_0_.rowfield1,
> <>!!data-_0_.rowfield2,
> <>!!data-_1_.rowfield1,
> <>!!data-_1_.rowfield2
> - indexes: <>!!data[0].rowfield1,
> <>!!data[0].rowfield2,
> <>!!data[1].rowfield1,
> <>!!data[1].rowfield2
> - $datapath$ is an optional parameter, only used in "array mode".
>It is a string used to filter a tiddler's fields/indexes to a specific
>"array" (represented above by numbers wrapped in brackets or a pattern of
>dashes).
> - When in array mode and $datapath$ is blank, there are 2
> behaviours:
> - If $datafilter$ == $schema$ (i.e. you are using the Schema
> Json Tiddler to also store data), the $datapath$ variable changes to
> "table_data".
> - i.e. "table_data[0].field, table_data[1].field,
> table_data[2].field"
> - If the $datafilter$ != $schema$, the row is built from a
> field/index array with no prefix.
> - i.e. "[0].field, [1].field, [2].field"
>
> Thus, we can use the table plugin in "tiddler" mode - keeping to the
> "every 'thing' is a tiddler", or a single tiddler becomes a database which
> can hold multiple "tables" within it.
>
> Ok, Sort and Fitler. These functions are performed "behind the scenes" by
> javascript. The widget catches
[tw] Re: [TW5] RenderTable Plugin Release
Hi TonyM,
Thanks! Great feedback and questions. This will help improve the plugin's
documentation.
Before touching on Sort and Filter I'll explain the parameters of the
widget.
So <> calls <$rendertable
schema="$schema$" mode="$mode$" datafilter="$datafilter$"
datapath="$datapath$" tablestate="$tablestate$" />
The last 2 are optional parameters:
- $tablestate$ is automatically generated by the widget if blank with a
<> macro, the input is just there for future code so this can be
ignored for now.
- $datapath$ is only used if $mode$ is set to "array".
Which brings us to the core of the widget.
- $schema$ must be a JSON tiddler structured as I explain in the example
Wiki: https://joshuafontany.github.io/TW5-RenderTablePlugin/#Table%20Schemas
- This is a "flat" Json Object (see my JsonMangler plugin
here: https://joshuafontany.github.io/TW5-JsonManglerPlugin/), which just
means there are no nested objects and the keys of the object are setup as
"paths" to function as nested objects when required ("dot notation" like
many libraries use).
- $datafilter$ is a regular Tiddlywiki Filter (meaning anything from a
single [[Tiddler Title]] to a complex set of filter chains) which defines
the tiddlers that will make up the total dataset of the table.
- The results of this depend on the next few parameters, but if left
blank if defaults back to the Schema Json Tiddler (i.e. you are using the
schema tiddler to also store data, see $datapath$ below)
- $mode$ is set to wither "tiddler" or "array".
- In both modes, the widget will detect if the current <>
is a regular tiddler or data tiddler and adjust the data calls to either
"fields" or "indexes" of that tiddler.
- In tiddler mode, the assumption is that each row will be a Tiddler
in the wikistore. Each tiddler from the $datafilter$ becomes a
<> variable, and then the column("field") definitions from
the
Schema are applied:
- either the field name defined in the schema for the current
column is used as a tiddler field/index name(i.e.
<>!!<> or <>##<>) and
that is
transcluded into the current cell,
- or, if a template is defined in the schema, which is a tiddler
that defines a <> macro (a macro so you can access all
the
various variables in the current table), it is transcluded into the
current
cell.
- In array mode, the assumption is that a "row" is a collection of
fields/indexes on a tiddler and any tiddler in the $datafilter$ can hold
more than one row.
- Each "row" would be a "flattened path" (again, see the
JsonMangler Plugin).
- fields: <>!!data-_0_.rowfield1,
<>!!data-_0_.rowfield2,
<>!!data-_1_.rowfield1,
<>!!data-_1_.rowfield2
- indexes: <>!!data[0].rowfield1,
<>!!data[0].rowfield2, <>!!data[1].rowfield1,
<>!!data[1].rowfield2
- $datapath$ is an optional parameter, only used in "array mode". It
is a string used to filter a tiddler's fields/indexes to a specific "array"
(represented above by numbers wrapped in brackets or a pattern of dashes).
- When in array mode and $datapath$ is blank, there are 2 behaviours:
- If $datafilter$ == $schema$ (i.e. you are using the Schema Json
Tiddler to also store data), the $datapath$ variable changes to
"table_data".
- i.e. "table_data[0].field, table_data[1].field,
table_data[2].field"
- If the $datafilter$ != $schema$, the row is built from a
field/index array with no prefix.
- i.e. "[0].field, [1].field, [2].field"
Thus, we can use the table plugin in "tiddler" mode - keeping to the "every
'thing' is a tiddler", or a single tiddler becomes a database which can
hold multiple "tables" within it.
Ok, Sort and Fitler. These functions are performed "behind the scenes" by
javascript. The widget catches messges sent by the sort/filter buttons,
performs some javascript wizardry to "recreate" the context of each cell
(all the appropriate column#, rowtiddler, rowpath, full fieldname, etc
variables -- gods that took a while to figure out), and then calls the
Wikify widget's code internally to render each cell's result. It then takes
those wikified cells, and performs the appropriate sort/filter function,
finally storing the final row-entity list (either rowtiddler or
rowtiddler+rowpath) into a field on the $tablestate$ tiddler. The table
automatically picks this up and uses this row-entity list to sort or filter
the table results.
So, when the underlying data is changed (for example, you change a contact
tiddler' email address to something that matches your previous filter), the
table will not update until you press the check-mark "Apply Filter" button
in the filter update. Your data
[tw] Re: [TW5] RenderTable Plugin Release
Joshua Fontany, This looks very powerful and sophisticated. To help me come to terms with its use can you please provide a little more information. Perhaps more contextual than technical. No need for a comprehensive answer, but making a start would help. When you say re-run you mean? Clicking the Tick against a filter setting and or re-open the tiddler? Could you give a list of all the elements involved in the rendering and data involved in a single table? As I understand it you are leveraging json formats to store the table data and schema? - How should a user approach this?, should they source json files with the data and build a schema to match? - What is the workflow you expect users to use? - Can Schemas for data be found elsewhere or within json formats itself? - Would the user build the schema then edit and data enter to build the table? - Once someone has built a table, and or populated it how can they share the table and/or its data? - eg; if I built a contacts database table how could I share it with people to populate it with their own data? I think such a solution will increase in adoption, and permit a greater degree of sharing, if we can build an ecosystem of shareable tables and data, which also includes methods to use them for real-world applications. Bravo on this work, you are adding value to tiddlywiki, such that it continues to exceed anyones expectations. Regards Tony -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscr...@googlegroups.com. To post to this group, send email to tiddlywiki@googlegroups.com. Visit this group at https://groups.google.com/group/tiddlywiki. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/5df36d28-bff1-4b0d-ac4c-9f5272b1242e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
