How To Coda a ViewOrLayout?
An alternative approach that works for reservations
Coda seems to suggest that you can select any layout you want when you open a row with OpenRow().
That is not true.
You can only open one layout per table (view). I filed this as a bug and the feedback was:
Hey Christiaan, thanks for bringing this to our attention! It looks like we only take table view arguments for the OpenRow() formula, so row layout names don’t work there. I do understand how that can be confusing considering it literally says “viewOrLayouts” and I’ll surface that issue with our product team.
I looked into the URL and although there is a property related to the Layout, it does not change when you select an other layout. It does however change when you create a view of your source table. This view has a different URL and this permits for a new layout. I did not see this at first. It was the great Coda connaisseur Joostmineur who showed me that instead of a helper table (as you see below) you can create views of the source table and use these views via buttons.
The advantage of working with views of the source table is that your code remains simple. You only have a ‘thisRow’ logic, while in the approach below you need to do a bit of extra filter work to relate the tables. The disadvantage is also clear: you end up with many columns in your source table you only need once in a while. Here the helper table is easy and practical, it keeps your main table clean. Buttons handeling exceptions are only part of the helper table
In short, you have two options:
- create a table view and use this as a set up for your layout.
- create a helper table (thus not linked) and use this for the layout
Maybe one day, Coda will make it possible to navigate layouts in one table without the need for an extra table (view). Until then, you have this blog to help you out.
The use case for an alternative Layout
I am working with reservations. Most are simple, people ask for a date (range) and a certain room. It is easy to confirm a request: a button is pressed and a confirmation email goes out, the room is made unavailable and gets linked to a person. Sometimes things get messy, you need to cancel, you need to rebook or you need to add only a part of the day to the initial reservation. These situations appear only once in a while and you don’t want to show buttons and related fields in the main screen. For these situations we need a second layout with extra buttons. Below the logic I created and a bit further how you can make it work for you. It took me a bit of time to figure out all kind of details I do not write about in this blog. I guess the same will apply to you.
After clicking on the options you got here ⤵️
Step 1 : create buttons
You need to understand what the main tasks are and which tasks are incidentally required. The main tasks you put in the main screen, the others you save for optional screens. In our approach most of the time the confirmation is as it is, only now and then there is a cancel or one needs to rebook.
Step 2: create a helper table
The buttons living in the main screen are part of the main table, in our case the Reservation table, while the buttons taking care of the options live a in a helper table.
In the helper buttons you use a filter to make sure that your data keeps aligned when you move between the main table and the helper table and back.
Step 3: design the layouts
The reason for this blog is that Coda only permits one layout per table, two layouts mans thus two tables. Per table we set up the layout and we make them talk.
Linking to the second layout means we add a row to the helper table and this row we fill out with some details from the source table. One of the details is a ‘key’, a match value we use to find our way back.
When we go back — using the match value — we modify the row in the source table and once done, we delete the row in the helper table, which remains empty after we are done. As such it a real helpe table, it helps you with a specific tasks. Nothing more.
Step 4: the code snippets
The link between layout 1 (thus the source table) and layout 2, the target table goes via the button options:
Once you click on this blue button, you open the layout of the helper table. When you are in the helper table, you have your buttons to execute all kind of tasks. In our example it is about sending templates. You go back via the green button.
This is how you can move between layouts while user does not see you are using a second table. The screen remains full screen and only the content changes.
This example is not perfect, but a decent preparation for any small business dealing with bookings and reservations. For clients I would for example add information on who changed what for which guest and when.
You find these examples in action in this template:
I hope you enjoyed this article. If you have questions feel free to reach out. Though this article is for free, my work (including advice) won’t be, but there is always room for a chat to see what can be done. Besides you find my (for free) contributions to the Coda Community and on Twitter
My name is Christiaan and I support SMB with calculations (budgets and planning) and I prefer using Coda to get the job done.
Coda comes with a set of building blocksーlike pages for infinite depth, tables that talk to each other, and buttons that take action inside or outside your docーso anyone can make a doc as powerful as an app (source).
Not to forget: the Coda Community provides great insights for free once you add a sample doc.
If you enjoyed this read and would like to get more Coda related content, please consider a Medium membership. It is it only $5 a month, and you’ll have access to every article ever published on Medium. If you sign up using my referral link, I’ll earn a small commission.
