Then I am even more confused. These fields indicate they have “canvas” options, ergo, my assumption that they are indeed canvas columns.
I was able to follow your Mega Trick example earlier and it was extremely helpful in resolving my UX objective. However, I’m still puzzled why Coda didn’t embrace a simple construct - i.e., setting a layout at the column level such that any drill-down of the “canvas” icon would enforce the Maker’s intent which is to provide different editor UIs that are indigenous to each column.
Based on the inference provided by the UI (above) as I established two different layouts accessed through each “canvas” column, I mistakingly assumed I was building unique editing dialogs for each canvas field. This, I now understand, is a misconception, but it was a surprising outcome. The first rule of software engineering - don’t surprise users unless its a delightful surprise.
Shouldn’t the “Canvas Options” simply include a selector that allows us to choose which layout to assert for OpenRow() actions for each specific column?
Once I realized that layouts were not assignable at the column level, I figured - well, perhaps I simply need a formula on each canvas column to assert the desired layout much the way your Mega Trick accomplishes this. Any column should/could have an action and I assumed that must be the right way to assert the desired editor in each column context. But that is also not possible (e.g., why the Mega Trick exists), resulting in what we might describe as “going around the barn twice just to open the door”.
Indeed, I’m old and I miss a lot of stuff, but in this specific journey, my own logic which drives my expectations seems to be invalid and actually worked against me.
Given Coda’s amazing capacity to build arbitrary layouts doesn’t it create an even greater duty to make it possible to assert layout editors for OpenRow() click events?