Make names of TABLES, CONTROLS and FORMULAs to be LOCAL to their page and not GLOGAL to the whole document?

Suggestion Box
1

Whenever I create a table/view or canvas formula or a control, that object’s name is seen across all the pages in the document.

So I have to deliberately make sure each name is both meaningful AND unique across the whole document.
As my clients documents get bigger and more complex, this is a challenge.

When I use the same pattern of tables/views, controls and formulas on multiple pages, this gets awkward.

I have adopted the convention of naming them as PageName_ControlName, PageName_TableName, … etc

SUGGESTION:

Ideally, each table/view, canvas formula and control name should be LOCAL to the page.
If I need to refer to it from another page, I should use the PageName.ControlName notation.

If this feature is introduced correctly, all existing references could be changed automatically in the existing formulas, without effecting their results.

To my mind, these things are LOCAL to the PAGE by default.
So I can have textboxes called ‘Input’ and controls called ‘Selection’ wherever I need them .

And if I refer to ‘ReferencePage.ItemsPerBox’ in a formula, I know which page that control is held in.

Respect
Max

2 Likes
2

I don’t think so. You are free to use a naming convention that suits you (like PageName_ElementName}, but within one doc there should be no duplicate names. The power of Coda is that you don’t have to know where something resides if you want to use it (anywhere in a doc).

2 Likes
3

100% agree that this is a problem.
This is really comes up with documents where you duplicate pages, usually by using a “designated” template page inside the doc.

In my case, I have a page per site. That page pulls data about the site from different tables, as well as let users add “prose” to that pages that is completely unstructured. The only way to do this is to have some sort of control on the page that all the tables reference to know what to filter.

Usually I would want to call it selectedSite or something similar, then when code duplicates the page, it created selectedSite 2 and then selectedSite 3, which isn’t super helpful. much more useful would be pageName.SelectedSite which can always be references from inside the page with something like thisPage.selectedSite

4

This is not the case when duplicating pages that have controls. Ideally you don’t want to do any naming at all, but give users the ability to duplicate a page with a premade button and make everything just work. Today we end up having controls named “thisWasMeanigfulNameOnTheFirstPageSelectionBox 2”, “thisWasMeanigfulNameOnTheFirstPageSelectionBox 23” and so on (Code just increments the number when pages are duplicated)

5

I leapt at the upvote button for this idea.

What Max is suggesting is not unlike scoping variables in apps. All programming languages support this and it is a commonly accepted architecture,

Tables, controls and formulas are a form of development handle that is evident in all facets of CFL. For advanced use of this concept, imagine both locally and globally scoped names that are global by default.

There are many use cases where this has advantages. Pages as templates is a big one. Cite a use case where this creates problems if it supports local and global scoping.

1 Like