Anyhow, if I recall correctly, Hypercard gave you the ability to define local and global variables. The local variable type was specific to the card it was one, while the global variable applied across all cards. Translating to Coda-ese, I’m wondering if there are section-specific variables as opposed to variables which apply across the entire document.
My use case: I have a table of projects, where each project is a row. I want to have a section in my document for each project. On that section, I use formulas to dynamically insert data from columns (from both the base table and related tables). The only thing that differentiates the formula for the Project A section from the formula on the Project B section is the value of Nth(). On Project A section, the formula includes “Nth(1)” and on Project B section the formula includes “Nth(2),” etc.
Right now, I have to manually change every formula on every section, and do the same for new section. What I would like to do is use a local variable (or even a constant) from the page, as in Nth(thisPage). I would set the value for each page manually, but I wouldn’t have to change the formulas from page to page.
Unfortunately at the moment there is no better option compared to what you are doing. If you have multiple sections, one for each project that all look similar and the only difference is that they display different projects, then at the moment you need to update all the formulas in the section.
Several other customers and we ourselves have run into this issue and are considering how to address this. Few of the options that we think might help are
When copy/pasting content, if the content includes controls (like select list etc) and formulas/tables, re-write all formulas in the content that point to existing controls to point to new controls that are created as part of copy/paste. With this approach you would be able to create a select list on the section to control the project for that section. This would be closest to the constant approach you described. The copy/paste would work across documents as well so.
Add support for scoped variables in a manner similar to what you described. The main behavioral aspect we will need to add support for over here is a mechanism to allow users to refer to global scoped variables with the same name vs local.
Thanks for your generous response. The two options you describe both have merits. The first one seems simpler, especially for users without any database or coding background. It is very intuitive if you copy/paste the control and the formulas that reference it at the same time (as in my use case).
But I think I would prefer the second approach, personally, for two reasons. First, because it forces me to be explicit about the expected behavior when I write the formula (or when I set up the control, depending on your implementation). Second, it probably applies to a broader set of use cases.
In any case, thank you for thinking about this. Loving Coda so far and excited for the future!
Thanks for your feedback John. Definitely keep it coming!
We will keep your input in mind as we work on handling for these use cases. You are right, both of these options could be used, and option 2 provide more power and is probably applicable to more options, but at the same time is a bit more involved.
What are your thoughts on both the options can co-existing. So simpler scenarios could benefit from copy-paste and more involved scenarios could benefit from the second approach.
Hey guys, I am in need on pretty much the same thing. And I am pushing this up a bit, if you are ok. Maybe you have updated your roadmap since then
Here is my use case:
I am working on a CRM based on one of the template I found, with user dashboards (with one user per page) that include a few buttons and tables view that I want to filter. All of these of course would depend on the user that the page is for.
So in my page I just want to see my contacts, my todos, etc.
I have added a select list on top with the team member.
So when I copy paste this on a new page, I have to change the name of the control.
Any way to have a local control name? Maybe in the future?
We are working on an improved copy/paste experience that should hopefully help with your scenario. We will start rolling it an initial version to users you would like to try it out and provide feedback. If you are interested we can include you in that rollout.
Sure!
I am not sure a better copy paste is exactly what I meant though
But I understand that this idea of local variables can make it more complex for many users. Anyway, let’s try this improved copy/paste
In particular - I am interested in using local control variable in the page such that I can have all tables point to local control for fitlers.
For example - I have created PRD Template and I’d like to have something like
PRDName = “PRD Template”
Table 1: Filter User stories where PRDNAME = PRD Template
Table 2: Filter Personas where PRDName = PRD Template
Table 3: Filter Requirements where PRDName = PRD Template.
This way PRD Page is just a filter to master table of User stories, personas and requirements. I don’t like how controls become global and they clutter control lookup in all the pages.
I could further simplify this if I could pick PRD Name = thisPage.Title. This way, I won’t even need to create a local control.
This would be very handy for what I am trying to do as well - rolling up OKRs by team, give each team a page to set thier OKRs, which pull from a master table, but filtered by the team using the current page
I’ve just spent an eternity trying to figure this out, and hit a wall. Is the ability to filter a master table based on the page it’s in possible? This would be so useful - my scenario is a master table with multiple clients in it, but each client should only see on their page the content that relates to them.
@Iyas_AlQasem if your goal to show each person their own rows, you don’t need separate pages for that. You can implement user-specific filters like this:
For everyone else, if one wants to have a thisPage, there’s a trick to do this:
Pick any control in the page or make a named formula with whatever (e.g. a text value with a space so that it looks invisible: " ")
Take that object’s .ObjectLink(). That’s gonna be your page URL. Sure, not really thisPage reference but you can use the URL to discriminate between rows in your master tables and filter by that URL or its /_suXXX part (the short page ID)
Whenever you duplicate the page and everything in it, the copied views will reference the copied object’s link. So no manual editing of formulas or filters will be required.
Finally, there’s no specifically local or global variables but you can easily use
new columns of a table to store any row-specific data, including temporary
extra tables to store whatever in them, not necessarily business data
