Add theme management to the Anvil Version Control for Dummies

I read the (Unofficial) Anvil Version Control for Dummies (all of it!) and I feel like one step is missing (I guess it was too short for me).

A limitation of Anvil is that it is impossible to define css, javascript and other resources in one app and use the app as a dependency to get other apps to look identical. This limitation is a problem for me, because I develop apps for one client, my company, and I want all of them to share the same look.

The workaround is described here. Here is my workflow:

  • I have an app called Standard Theme. The app has only one form with a few labels, links and other UI elements so I can see how they look. There are also some elements to test some javascript functions that I need in all my apps. I have a cloned git repository on my computer.
  • When I create a new app I clone it to my computer
  • I delete its theme folder
  • I copy the theme folder from the Standard Theme app to the new app
  • I push the new app with the new theme folder back to the Anvil server

When I want to change the company theme or when Anvil adds some features that I want to include on my apps I edit the Standard Theme app so it looks right and I pull it to my computer. Then I repeat the pull - replace theme folder - push for all the apps that I need to update.

2 Likes

@stefano.menci worth noting that the first post in (Unofficial) Anvil Version Control for Dummies is a wiki and is editable by anyone who wants to add to it… so if there’s something missing you could add it straight in for future readers of that post.

and I think @AWSOM is giving out prizes for anyone who reads it all… :trophy: let us know what you win

2 Likes

I forgot to mention another point that has not been addressed in the tutorial and I deal with on every app I make: http endpoints.

The Anvil version control based in development / production doesn’t work with http endpoints. All http endpoints always execute code from the published version, never from the development (unless there is no published version).

The workaround is to either un-publish the app while working on the endpoints, with the risk of breaking production traffic, or to use the two app trick and do the development and testing on an app while the production traffic uses the published production app.

Sometimes I felt I would be so good that I could just un-publish, do a quick editing in the ide, quickly test the endpoint, then publish, and no one would even notice. I had traffic on the app with the normal users, but no traffic on the endpoints, so it felt safe.
Then obviously the phone rung while I was in the middle of editing, I got distracted, didn’t notice a syntax error and the whole app was down because every call to the server would complain about the syntax error.

So now I always use the two apps trick. If I don’t have the development app (which happens often with simpler apps) I clone it and create it, do my tests, then copy and paste the code between the apps and delete the test app.

PS

I had not realized that. If I find the time to edit it I will do it (not very likely, we will see)

2 Likes

Thanks very much for patiently reading the whole article and for both your additional suggestions Stefano. I think they would make for a really good Level 12 and Level 13 chapter respectively since they are (from my perspective and current knowledge) further levels of sophistication. It shouldn’t take you long to add to the post - the nice thing about Wikis is that other people can help shape and polish what you’ve contributed.

If you could get the ball rolling and just create two more collapsible section and copy your two posts under each of them, I think other user would benefit.

All the best,
Peter