Customizable row metadata

[nbenn]

(moved from nbenn/prt#4)

With (greatly appreciated) extensibility being in focus with recent 'pillar' development, one thing that remains locked-down is row-metadata (currently in the form of a seq_len() generated rowid column). My feature request if two-fold (and nested):

1. make what is printed as rowid-data customizable in order to enable for example 'data.table' style printing (showing head() and tail() of a table)
2. maybe even generalize the single rowid pillar to one or more metadata columns (which all are repeated in multi-tier prints)

Allowing for arbitrary meta columns would enable display of further row metadata such as partition information in a partitioned table.

[krlmlr]

Multiple columns could be displayed by using a compound pillar.

Is it ever relevant to show metadata also on the right-hand side of the body?

I think this must be a ctl_new_rowid_pillar() generic, not a tbl_format_...(), because it would be called internally from ctl_colonnade() even before constructing the rest of the body.

Would you like to take a stab?

[nbenn]

Is it ever relevant to show metadata also on the right-hand side of the body?

I guess in the interest of balancing extensibility with code-complexity, fixing meta display to the left would be sufficient for the time-being.

Would you like to take a stab?

I'm happy to as time permits. This is not high priority for me right now (as for my purposes I have a hackaround in place). But as soon as I find the spare time for this, I'll have a go.

[nbenn]

I today finally got around to having a look at this. As discussed, as a first step, I added a ctl_new_rowid_pillar() generic and moved some stuff around:

master...nbenn:f-260-meta

I'm happy to open a PR do get a discussion going, if this is ok with you.

While thinking about how to use this to achieve my original goal, I started wondering about ctl_colonnade(): would you be open to exporting this function (possibly marked as internal)? Or maybe even turn it into a ctl_new_colonnade() generic?

I'm happy to elaborate on my thinking behind making ctl_colonnade() accessible, but first: how do you want to proceed? Do you want me to experiment a bit and then discuss a compound PR? Or do you want to try to keep things separate as well as possible and discuss ctl_colonnade() in a separate issue?

The current state of row-metadata is just a first iteration. I definitely would like to play around and see how having a compound pillar as rowid would work out. For such an extension, however, if specifying a customized tbl_format_setup() method, I feel it would be useful to have access to ctl_colonnade() in some form. Otherwise a lot of logic has to be duplicated in the custom tbl_format_setup() method.

Happy to discuss further at your convenience.

[krlmlr]

Thanks, let's start with a pull request.

Instead of a ctl_colonnade() generic, would it work if we provided a generic that creates the rowid pillar?

[nbenn]

The reason for asking about access to ctl_colonnade() is that for certain types of extensions, you'd potentially want to supply an implementation for tbl_format_setup(). Off the top of my head:

• data.table style printing: tbl_format_setup() would then call head()/tail() and pass the subsetted df on to ctl_colonnade()
• multi column metadata: say I have a tbl class where some columns represent metadata, then tbl_format_setup() would row-subset my data.frame, separate away the meta columns (maybe attach them as attribute to the df passed along), and call ctl_colonnade() and later a custom implementation of ctl_new_rowid_pillar() would construct a compound pillar rowid column

In such cases it would be convenient if some function that contains most of the logic of ctl_colonnade() were available. Or am I missing something? Or do you disagree?

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue and link to this old issue if necessary.