Organizing Forms

Does anyone have a good way to organize their Forms? I’m just getting started on my first functional project with Anvil & already I see that I’m getting disorganized.

For instance, here in my Forms section, I have several pages, then templates for the repeating panels on those pages. Now that I’ve discovered that other users can share assets, I’ve downloaded david.wylie’s awesome progress bar & have assets on that list as well: https://imgur.com/a/6kVyc

I can rename all of them to be prefixed with their ‘type’ and that will help me avoid clicking into something I don’t need. But is there a better way?

1 Like

I’ve been wondering about this as well, without much success.

I was thinking of asking for “folders” where i can group like forms together. I’d welcome other suggestions that we could put forward.

For example, I have several sections in my apps, such as “clients”, “suppliers”, “tools”, “Stats”, and the like, each with several forms including CRUD and repeating panel line items. It’s getting a little unwieldy.

I was thinking, for example :

(folder) STATS
(subfolder) OVERVIEW
(subfolder) FINANCIAL
(subfolder) ANOMALIES

Agreed. Folders would be optimal. I just assumed that something like that already existed & I missed it.

1 Like

after several years since this topic was created, I’m wondering if is there any solutions for organizing Forms (i.e. using folders)

New projects will be organized using packages. Create a package to be a folder, and put Forms under them.

If you have an old project created before packges, there’ll be an option to convert it to the package structure in one of the … menus.

4 Likes

I’m using this exact approach.

Note that when you turn a “flat” Form (formname.py with formname.yaml) into a Package (formname/init.py with formname/form_template.yaml), the .py file actually moves within the folder hierarchy. This can require changes to related import statements

  1. Within the converted .py, referring to other modules/packages
  2. Within other modules/packages, referring to the converted .py

This is not a bug. This is simply the way nested Python packages work.

1 Like