I want to be able to manipulate pages as though they are rows
Long story short: Let me make a column type called Page that is built out of the contents of a single Row, let me edit it with the flexibility of a regular Page, but the structure of Table Detail view, let me use thisPage
to access columns in its row, and let it inherit its formats from the columns themselves.
Rows are great because I can:
- Create new ones with buttons
- Update them with buttons
- Sort them with filters
- Format them with conditions
- Nest other tables inside them
- Link other tables/rows to them
- View them in various states (hiding columns, etc.)
I want to do all of these things with Pages as well.
There are a range of requests out there with a common thread related to this proposal. Here are some of them in a single list:
- make a section for each row in a table
- generate a text document from a table
- access thisSection() as an object
- share portions of a doc
- copy sections between docs
- create and manage personal templates
- creating private templates for repeated section structure
I think there’s a way in which all of these can be addressed by a single, simple interface. There are some things I would like to do that this would enable:
- I could dynamically generate documents (press a button to populate a page with information)
- I could dynamically generate presentations (someone fills out a survey, their information builds a presentation that determines which Coda sections I show to them, in what order, and with what information)
- I could reuse the same structure of a document in multiple places (the much asked for “template” feature)
- I could build a wiki that simultaneously merges table structure and page structure
The way I would want to interface with this is as a new column type called a Page (or Page Template or Page View or Dynamic Page or Larry Page, not too concerned with the name rn).
Rather than a Select List or a Lookup type column, a Page type column lets you build a Page out of the contents of your current Row. By selecting Page type you turn each cell in your column into something that looks a lot like a normal Text type column, however this one can be built much like the Customize layout feature of Detail view:
Unlike the current Customize layout feature, however, in the Page cell it looks like you are editing a normal Coda page, with the familiar formatting options, table views, etc. The only addition is that you can access the content of the current row with formulas like thisPage
(because technically, your page is a row! #namespacesforfree)
You can’t create new tables in this view, only reference existing ones. This isn’t a true page, just a fancy way to view a row. Just like with the detail view of a table, you are able to edit the contents of the fields in the row. So if I have a field called, “How are you feeling today?” I should be able to see that and edit its contents and input my own, “I’m great!”.
You are able to show views of tables, too. Right now, duplicating multiple views of tables is quite an ugly experience. I now have a View of Sentiment Tracker 3 12 in one of my Weekly Meeting docs. That’s ugly. Instead, this would let me select a table to view, then apply a filter to the table. If I only wanted to show the sentiments related to this meeting date, it might be something like Filter: thisRow.[Meeting Date] == thisPage.[Meeting Date]
where thisRow
is talking about the row in the Sentiments table and thisPage
is talking about the row related to this Page in the Table where this Page type column is held.
Calling Activate
on the Page type Column opens it like a regular Coda Page, creating a temporary page associated with it in the sidebar, optionally it can be saved so that it remains after switching to another Page. There are options to automatically create a new page whenever a new row is added to the Page’s source table. These types of pages will be a bit different from standard pages. They will be somewhere between the Play and Edit type permissions, where source content can be changed (you can click buttons, edit text, and check boxes with permanent effects) but the structure cannot be changed (you can’t move a table below another table, because doing so changes the structure of the Page, which would affect all the pages in that column). If you want to edit the page you have to hit the Edit Page button under the three dots
or hit the edit page button under Page Options.
I believe this would be more flexible than the current Detail view too, so your Detail Layout options would also list any Page columns you might have:
so you can render them inside the bounds of the current Detail view.
Text formatting can be inherited from the column format itself. So if your page has, thisPage.[Customer Name]
in it, you can edit the formatting on the Customer Name column and it will automatically update the Page formatting.
This is all fitting a bit too well. Was this the plan all along?
To try a Shishir / Matt eigenquestion (Right Click > Add to Dictionary): Is Coda only a tool to manipulate Tables inside Pages, or also Pages inside Tables?
To reveal my bias: the former is COBOL, the latter is lisp.