A recursive folder hierarchy - Is this actually working? Calling the experts

1

As probably many other Coda Maker newbies, I’m looking for the easiest way to build tables with some kind of hierarchal structure.

I read about rather complex ways (to me) to make sub projects and hierarchy in the community. But, as I started to play with a lookup into it’s own table and changed the Display Column, I suddenly made a kind of recursive loop, and a complete path was revealed. I haven’t found a structure like this in other docs.

[Project Database]

So, experts: Have a look at this. To me this seems to work. I get some issues. Coda doesn’t seems to decide if Project Name DB is text string og data, so getting data gives different formatting, depending on formula and occation. And there is a @ that shows up in the path, as you will see in the drop down selector.

Still, I have managed to find workarounds so far.

Is this a good way to make hierarchy / folder structure?

3 Likes
2

@Lars_Kristian_Aasbrenn

welcome to the community

and congratulations on building such an impressive document, containing an impressive recursive parent/ child tree.

all my documents so far have used fairly static data structures; seperate tables for parents and children.

and for Customer/Order/Product or Client/Project/Task use cases, this is simple and straightforward

but for more sophisticated use-cases, like Work Breakdown Structures or Stock Control Parts Explosions, this recursive approach is ideal.

and i can also see it being useful for Knowledge Management and Note Taking systems as well.

so, well done for

  1. designing and implementing this
  2. generously sharing this with the community

this is keeping in the BEST traditions of the coda makers community

salut
max

2 Likes
3

hi @Lars_Kristian_Aasbrenn ,

I never use Coda in this way. The idea of a lookup in the own table I first came across when somebody showed who was in charge (the boss) of who by using a lookup on the names of the people in the list. I am actually quite happy with the Coda structure as it is.: rather simple and only one place to update.

You can get rid of the @ thisRow logic by creating a column like you see below OR by using ToText()

image
image2866×1016 149 KB

image
image1576×449 45 KB

Cheers, Christiaan

4

Hi Christiaan,
I’m not sure if you have seen the recursive part here. It’s not just a lookup in the own table, it’s a tree without limits. You only use the green columns. No where else to update.
I have updated explained more with text below the database.

Best Regards,
Lars Kristian

5

Thanks for kind words Max! It was in fact my plan of a Personal Knowledge Management that led me here.

I’m very curious to see if this is a known solution, and hope Coda will tell if they will keep this possibility, as it’s not documented, as far as I’ve seen.
Lars Kristian

6

hi @Lars_Kristian_Aasbrenn , I did not fully understand the approach when I saw it. I guess your back ground is in development and you might have applied this logic in other languages? That having said, I can imagine applications of this approach. Well done!!
Cheers, Christiaan

7

@Lars_Kristian_Aasbrenn, this is a great doc and a great way to accomplish nested dependencies!

This is the first time I’ve seen this tried in quite a while. Here’s a post from a long time ago with something kind of similar, but the setup is much more complex.

And I gave something sort of similar a try here to track dependent date chains.

https://coda.io/@ben-at-coda/schedule-tasks-with-dependencies

All different solutions, but I think your setup is the best way to see the hierarchy as a label to know where you are.

Great post, and thanks a ton for sharing!

4 Likes
8

Thanks Ben!
I would just mention that the folder column “Project Name Indented” is just an example, and not my main point here. If you look at the dropdown above the table, you will see that because of the recursive approach the tree structure unveils automatic there as well, without any extra code.

This technique can of course be used for all kinds of situations where you need a unlimited tree structure. Like sub tasks, sub projects, folders for collecting data, tag tree, etc…

I would really like to know if this approach is “safe” to use, meaning: Will this recursive lookup work inn all further improvements of Coda or is it a solution that might suddenly disappear, because it was not meant to work this way?

1 Like
9

+1 for simply using ToText() to get rid of the @

10

I think this approach is fine to use. There are some implementations that can get caught in a circular reference if your top data item references itself, but I think your setup avoids that. You can also add a filter to your lookup column in the “Item Settings” to filter out the row you’re in so it can’t be chosen.

I don’t see any reason why you couldn’t use it or why it would stop working.

2 Likes
11

ToText() does work, but if you change the display column of that table you’re looking up to, it’ll change the text. So if you want to keep a specific title even if the display column changes, it’s generally better practice to be specific to the column.

  • [Row Value].[Column 1]

Instead of

  • [Row Value].ToText()

Either way works, just a small nuance to keep in mind.

3 Likes
12

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.