How to pass information to a duplicated page

Showcase
1

With the new duplicate page action, it’s quite nice to be able to create a template of a page and duplicate it.

However, there is an issue with this approach. Sometimes you will want to pass information to the new page. For example:

  1. In a customer wiki that contains information about your customer, you’ll want to pass the customer name
  2. In a meeting doc, you’ll want to pass the current date (if you have a new page for each meeting)

This doc offers a (dirty hacky) solution to that problem.

Overview

The only information we can pass to the new page upon duplication is the name of the page.

Then we need a way to get the information out of the page title.

Here’s the doc for you to look at, below is a summary of all the tricks that were used.

1. Create a Button on your Template Page

This can be any button, it’s used to get the url of the page, but it’s nice if it does something. In this case, the button creates the new meeting.

2. Create thisPage formula

image
image1144×320 31.3 KB

[yourButton].Url()

This is what we’ll extract the title of the page from.

3. Get thisMeetingDate

Now, create another formula called thisMeetingDate. It looks like this:

thisPage.ToText().Split("/").Last().Split("_").First().ToDate()

This formula extracts the date part of the url.
If the url is: https://coda.io/d/_dV-vk_8iWzc/Meeting-Template_su55M

  1. Convert it to text
  2. Split it along forward slashes “/”
  3. Grab the last bit Meeting-Template_su55M
  4. Grab the first part
  5. Convert it to a date

4. Create the New Doc Button

image
image1300×1168 61.3 KB

Under Action make sure to pass in the current date as the name of the new page:

DuplicatePage([Meeting Template], Today())

Done!

That’s basically all there is to it! You’ll notice the actual doc has a bit more to it, but that’s just so that it’s useful, this information covers the heart of what’s needed.

Doc is also published here:
https://coda.io/@connor-mccormick/simple-meeting-doc

6 Likes
2

This is excellent stuff. Adding your thisPage formula to my Notes template and the 2 buttons you describe has gotten me way closer to being able to use Coda as a note-taking tool (in addition to the 20 bajillion other things).

One thing I don’t understand though is the need for the “manual change” checkbox. I think I’m probably missing something in your own use case. If the “create new meeting” button is passing the page’s URL to the Meetings table, that table will always render the current resolved name of the linked page, right?

3

Good question!

Checking and unchecking that button updates the meeting date after changing the page title.

Try changing the title of the doc to experiment with it.

Due to Coda mechanics I don’t really understand, the formula to figure out the url of a page can be forced to update with checking or unchecking the box.

You can see that thisPage is actually more complicated than I made it look in the original post.

If([Changed Page Title?], [Create New Meeting].Url(), [Create New Meeting].Url())

Just allows you to update the meeting date after changing the title.

4

Ahhhhh, okay, that makes perfect sense. So you’re basically using it to force a UI refresh of sorts?

5

Basically, yes. Though I’m not sure how it works.

1 Like
6

Hi @Connor_McCormick , following up from the other thread about pages-as-rows, you talk about using this setup for meeting notes and wikis. Could you talk more about how you passing information along to these new pages contributes to these workflows?

7

Basically, this is my workaround for not being able to manipulate pages like rows. Coupled with the thisPage hack I can get the basic functionality I want, but it’s kind of backward.

I’m using this for a meeting notes doc. I want to be able to make a page that is related to a row in a table. This way I can store information about that page in the table, or look up information from other tables related to this page and display it on the page.

For example, my Meeting History table contains all the meetings that have happened and a link to their page. It looks up the Meeting Rating that took place on the date of this meeting and displays it next to the Meeting Duration and the link to the Meeting Page.

The Meeting Page itself will look up the tasks created in the previous meeting, as well as run other formulas. I’ll also make notes in the page and add tables as I need them.

In my ideal world, the content of the page is controlled by the columns of its parent table. This way, when I change a formula in the parent table it updates all prior meeting pages.

This is important because if a template has an error and I duplicate it a couple of times before catching the error, I have to go back to each of those duplicated pages and fix the bug manually. What I want is a master parent table that has all the formulas within it, then the page can just look those up with much simpler formulas.

For example, in my parent table (in this case the [Meeting History] table) I might have a column like [Unfinished Tasks Due This Meeting]. Its formula might look like:

[Tasks].Filter([Done].Not() AND [Due] <= thisRow.[Meeting Date])

Then in the page associated with that row, I might have a table called [Tasks Due], it would be a view of [Tasks] but its filter function would be really simple:

thisPage.[Unfinished Tasks Due This Meeting].Contains(thisRow)

This way, if ever there is an error with my formula [Unfinished Tasks Due This Meeting], I can update it in one place. After all, I want all meeting pages to be the same except for the ad hoc information I may add in like templates with the slash command, tables, or notes.

So, the hierarchy becomes:

  1. The parent table, which does all the heavy lifting with fancy formulas
  2. The page, which can reference its row in the parent table (with thisPage) and look up the fancy formulas the parent table performs
  3. The views of template page, which is duplicated by the parent table whenever a new meeting page is needed

The only reason I’m currently trying to pass information into the duplicated page is so that the page can know where it came from. If I pass a uuid to it then it can look itself up in the parent table. Right now, that ‘uuid’ is the date. If the page had a built in thisPage function, I wouldn’t need to pass information to the page, it could look it up itself.

If this doesn’t make sense, please let me show you my meeting notes doc over a 20 minute zoom meeting. I super highly respect your design philosophy, so I’m not trying to impose my will, but I really want to ensure the pain points I’ve faced with trying to create templated pages can be avoided for myself and others.

2 Likes
8

@Coda_Zac

Ok, there might be an exception to the thisPage idea. It may be the case that a page can be referenced by multiple tables. If that’s the case, then thisPage would not work (since it wouldn’t know which table to reference).

This means there are two options (with the scenario I outlined above):

  1. Pages that are rows must only have one parent table
  2. thisPage becomes an object like any other lookup object that must be found with a formula

Scenario 1

In the first scenario if you wanted to get the date associated with this page then you would just use the formula

thisPage.Date

Scenario 2

In the second scenario, if you wanted to get the date associated with this page, but that Date column was in a different table (we’ll call it [Other Table], and we’ll assume that the name of the column containing the page reference is called Page) would be:

[Other Table].Filter(Page = thisPage).Date