Mega trick: Different "Expand row" layouts for the same row

Most likely you’re familiar with “Expand row” feature that lets you see a popup for a row by clicking here:

And perhaps you know the action Activate() to open that popup programmatically with a button, or at least used the “Add new row and open for editing” checkbox.

And also you may know that you can configure row details popup layout just like you can edit the layout in Detail view:

What you may not know though is that you can configure this popup’s layout individually per each view of your table.

Now, when you use thisRow.Activate(), the popup that will be brought up will always be the one of the master table. However, if instead of Activate() you use view-specific URLs like #_tuAPf/r{RowID}&modal=true, you can summon popups as configured for other views.

:point_down: Watch the video, and you’ll get it

With this trick you can have a compact table with a few buttons, each of them configured to open popups with only certain fields. E.g., if it’s a table of Classes, you can have one popup that deals with cancellation and rescheduling, another popup with program management (lesson doc links etc), another popup to review attendance and homeworks, and so on. Just make a few views that you can hide away, then configure popups differently for these, and then open the respective popups with buttons set to OpenWindow() different links.


Oh, turns out I’m not the first one to discover this :slight_smile:

Props to @Krunal_Sheth

Dear @Paul_Danyliuk,

Great that you highlighted this method again in a very detailed way.
Looks like only a few picked this up and somehow Coda doesn’t make much publicity on its potential, while in my eyes there is enough to explore as you already gave some clear direction.

Great job again :boom::boom::boom:

And one more thing: you can use UIDs and not RowIDs. This is especially useful if you want to open a recently created row that possibly hasn’t yet had a chance to have its RowID assigned, or a doc used in Play mode:

How could this work for a button that’s adding a row to a table? For instance, I have a table of candidates for jobs, and a table of interactions. From the table of candidates, I want two buttons, on that adds a row for a simple interaction, and another that adds a row to the same interactions table, but with interview fields exposed. I want the button to add a row, and expand the row details with different views depending on which button is clicked.

@Matthew_McAllister I think this is a great opportunity to test the frontier and check back! I’d make a few views of the table, edit/customize the default pop detail, then create buttons that addrows and activate those views. Let us know what worked!

It doesn’t fix it, unfortunately. I’ve noticed on other threads that when you add a new row, the view of that expanded row at the point of creation is based on the Layout of the original table, not views of it, even if the button is set to add a row to a View Table.

I’ve read about a bunch of workarounds that get quite involved, but this feels like a simple add row error with buttons and the tables they point to for Coda to address, so I’m currently waiting for that.

Broadly, it feels like Layouts in general is in need of a refresh. Being able to organize hidden fields so that the “Show Hidden Fields” becomes more of a “show more” in certain contexts, adding heading sections, and more options to visually break things up feels overdue.

Absolute agree that layouts needs more work.
It feels like they were a really nice idea to present a row in customisable way, then the customisation was abandoned.

Yes, the can be customised to a small degree but there are no colours or groupings to help make a really attractive UI.

Yet. Coda has been shipping a lot of features at a brisk pace :slight_smile:

I would use this also.

Perhaps the desired row display configuration could be made available as a parameter in the button UI?

And therein lies some of the potential issues.
There are still some quite fundamental problems with Coda (no text input box, performance with large tables, sharing of tables across disparate groups of people, difficult editing for reasonably complex formulae) that haven’t really been addressed. There are some clunky workarounds, but not true solutions.

We all have our own opinions, but I do feel there are some fundamentals that still need work ahead of the sexier stuff.

1 Like