Demo of my various libraries

Show and Tell
1

I’ve started putting together a demo app to show how I tend to structure apps using my various libraries (ORM, Navigation, Messaging).

Within the app, everything in the ‘client_lib’ and ‘server_lib’ packages has come from one of those libraries. The specific code for the app itself is everything else outside those.

It’s a simple ToDo app with a bit of GTD terminology thrown in:

https://anvil.works/build#clone:HLOVLG3WXFZUKDLW=MXRZPXY5GODJWDLOVGLLKYEN

11 Likes
2

Now with the inevitable bugs found just after publishing here fixed!

1 Like
3

The aim is to have to do as little as possible for basic CRUD operations in new apps. The orm library now has mixin classes for use in crud forms so there’s little or no code to write.

The only thing stopping full automation is needing to use different components depending on the data types of the attributes and I’m mulling whether to do something about that too…

2 Likes
4

I can report it starts up OK after switching the server mode to “Basic Python 3” (for folks on the Free plan).

I ran into this error, though, when I tried to save a new task with a blank “Project”:

TypeError: 'NoneType' does not support indexing. Did you initialise all data binding sources before initialising this component?
Error binding text of label_3 to self.item['project']['name']: `'NoneType' does not support indexing`
at client_lib.crud.mixins, line 93 called from client_lib.crud.mixins, line 68 called from client_lib.crud.mixins, line 79
5

Yeah, everything is required in there at the moment. I haven’t done anything about optional fields or any form validation.

6

I’ve amended the task model to allow for missing/optional context and project - and that solution looks like a pattern that might be worth adding to the ORM library!

1 Like
7

Decades ago, Oracle Designer brought GUI and data definitions together in an integrated data dictionary (which I’ll abbreviate as IDD). Each field not only had a data type (a “domain”, in DB parlance), but details on its GUI data entry widgets.

For example, you’d specify not only the distinct values (“codes”) of an enumeration, but how each was to be worded in your dropdown list, and the sequence in which they should be displayed there.

The same idea is used (to very good effect) in the open-source organizer TreeLine (written in Python 3).

The concept is still valid today. You might want to “borrow” the idea.

I’ve explored the idea in some depth. With the right details in the IDD, one could actually generate much of the needed classes and UI code.

8

Yeah, I’m old enough to remember those too. I’m working my way (slowly) towards that sort of thing!

9

Then you may be more interested in TreeLine. It’s not just an example. It can actually help you build and formalize your own IDD. You can make it embody your own IDD specification. (I’ve done that on at least 2 occasions.)

2 Likes