1/21/2025 Finally implemented Copying Course to Term. Thought I had trouble with units and lessons becoming orphaned after parent course was deleted but that doesn’t seem to happen now. Something to watch out / test for though. It appears that all child rows are deleted by ON CASCADE, so that when a course is deleted, the units, lessons, and lesson_dates
I’ve been making a ton of progress though I haven’t been writing it here. Major decision to be made regarding how to store term dates. Currently I have a table for instructional days and a table for non-instructional days but only one of them is used in the application, so the non-instruct table is empty. Since these days are mutually exclusive I have a challenge in that I need to make sure any change to one is checked against the other and handled appropriately. ...
Great progress on the web app. I’ve just about matched the feaures of the fyne app and about to surpass. Surprised at how easy it was to implement the Shift Lesson UI. Quality of everything is much better and I feel more confident in how everything is laid out. Having fun returning to web dev, and just absolutely love working with HTMX. I happen to have made all my lesson names e.g. Lesson 1.2 but this is redundant info with the Lesson Number and Unit Number and makes the Name field/column pointless in my case. A teacher would certainly to display the numbers, but they also might want a name for a lesson. I am thinking that perhaps I should display the lesson number but I should make the name separate, more like a name that briefly describes the topic or activity, less like the designation number. One problem is this would require fetching the unit number from the units table whenever I need to display a lesson, but that might not be such a pain if I just add it to the SQL queries. ...
Decided to shift to building a web app instead of a Fyne app. One big reason is I want to be able to display slides in markdown and html side-by-side. It will also make deployment much more straightforward. I am starting to think it was a mistake to decouple lessons, slides and files. Now I think I should just make copies of everything with each new quarter instead of trying to preserve space. So the slides and files will now be stored in lessons directory named by lessonID, and accessing outside the web app will still not be feasible but at least it will all be in the same place. ...
Shifted to lesson planning today and had a lovely time working with the files through the app. It’s still a little cumbersome.
1/3/2025 Big progress today. I’m now able to delete the courses directory and re-generate it from the app’s database and file system. It’s pretty fragile though, and there are some things that need to be fixed ASAP: Slides are tied directly with a lesson id, so the next semesters lessons won’t inherit those slides. Big problem! I’ll need to figure out how to do this – I think I will just do the same as what I’ve done with images and files, but I’m not sure if this is optimal or not. docs root folder is not generated, so js, styles etc. must be manipulated manually. only courses folder and below is generated. Need to make deleting this directory part of the generation code. Courses main page image is not an attribute of term, but should be (very minor issue)
1/2/2025 Name-based directory naming Pros: I can find a lesson outside the application Cons: Potential for name collisions, caching builds is less feasible Id-based directory naming Pros: Caching build is more feasible
1/1/2025 If I change my site generator route naming to match the id-based structure, then the name-change possibility is not as much of a problem. Another problem with name-based structure is the potential for name conflicts - I need to protect against that somehow. But if I’m doing a full rebuild each time, the name-change possibility is no problem at all apart from the name-conflict issue. But the nested structure mitigates this risk since 2 lessons in the same unit having the same name is low-chance. ...