podlite inspirations - table

[amitu]

Note: Only the table part of this discussion is worth considering, other stuff are already handled by other "better" proposals.

Went through https://podlite.org/specification, and it sparked some ideas:

Table

We should borrow table syntax from them, as thats neater than the corresponding "markup" syntax.

-- ftd.table:

                        Secret {bold,
        Superhero       x: 20 : Identity}    Superpower
        =============   ==================   ===================
        The Shoveller   Eddie Stevens        King Arthur's
                                             singing shovel

        {cell, colspan: 2: Raja}             Master of cutlery

        Mr Furious      {img, src: foo.png,  {cell, rowspan: 2:
                        width.px: 20}        Ticking time bomb
                                             of fury}

        The Bowler      Carol Pinnsler       

ftd.table body can be only a "static string" (available to compiler statically, can be reference to static variables, but not dynamic variables). For dynamic data it better to use the later syntax, instead of converting data to string and then trying to get fastn to parse the string back.

complex table

-- ftd.table:

-- ftd.row:
    -- ftd.text: Fruits
    -- ftd.text: Bananas
    -- ftd.text, row-span: 2: Vegetables
    row-span: 2
-- end: ftd.row

-- ftd.row:
    -- ftd.text, column-span: 2: Carrots
    -- ftd.text: Crunchy and orange
    > with a longer para
    -- ftd.image, column-span: 2, row-span: 3: /path/to/carrots.jpg
-- end: ftd.row

-- end: ftd.table

We will have to make column-span, row-span "universal arguments" that can be passed to any components (and compiler will make sure they are only passed when they are children of a ftd.table.

ftd.table will have to make sure that each row has same number of columns, and the row-span, column-span have meaningful values.

We can easily nest ables here.

Tables Over Data

-- ftd.table:
data: $data
header: some-header-component
ui: some-component

Here the data must be a list of T and some-component must take only one non optional argument, type caption T. Both some-header-component and some-component should use ftd.row as top level elements and must have right number of children with row/column span values.

For this to work we will have to support generic. We can implement generic only for ftd.table for example, as a special compiler hack tho, we do not have to expose generic as a user accessible feature just to implement ftd.table.

---

Inline headers

-- foo, x: 20, y: 30: some caption

Is shortcut for

-- foo: some caption
x: 20
y: 30

Longer Caption

-- foo: 
This attribute specifies the number of columns a cell should span 
horizontally. It allows cells to merge and occupy multiple adjacent 
columns, creating a visually unified cell.

The body of foo.

If there is no newline between section line, and caption, the first "paragraph" is assumed caption.

We can also start the caption in caption position and continue in next lines.

-- foo: This attribute specifies the number of columns a cell should 
span horizontally. It allows cells to merge and occupy multiple adjacent 
columns, creating a visually unified cell.
x: 20
y: 30

The body of foo.

I like the later example actually.

Terse Headers

-- foo, x: 20, y: 30: This attribute specifies the number of columns a cell 
should span horizontally. It allows cells to merge and occupy multiple 
adjacent columns, creating a visually unified cell.
z: 40, src: $foo, id: 23
y: 30

The body of foo.

Here we have passed some headers in section line, and we have used terse syntax for adding multiple headers, z, src and id in same line using the comma as separator. This can not be used if the value of any header contains comma, in that case you have to use the
header on its own line.

Header continuation

-- foo: 
x: This attribute specifies the number of columns a cell should span 
horizontally. It allows cells to merge and occupy multiple adjacent 
columns, creating a visually unified cell.
z: 40, src: $foo, id: 23
y: 30

The body of foo.

Compare it with the older continuation proposal.

-- foo, x: 20, y: 30: This attribute specifies the number of columns a cell 
> should span horizontally. It allows cells to merge and occupy multiple 
> adjacent columns, creating a visually unified cell.
some-header: this is also a long header,
> and can span multiple lines
z: 40, src: $foo, id: 23
y: 30

The body of foo.

This syntax is less error prone, it does not break easily if header or caption values contains color characters.

Inline Styling

They have nice B<text to show as bold> syntax but I still prefer our older "markup" syntax {bold: text to show as bold}, and we can extend it to {bold, x: 20: this is bod with x property also set}.

[Arpita-Jaiswal]

https://github.com/orgs/fastn-stack/discussions/477