divinum-officium
divinum-officium copied to clipboard
DivinumOfficium
Separate Logic from Display
Would you be open to PRs that start to separate logic from display?
For example, instead of interleaved "Determine today's reading" and "print HTML for the reading", the result of this would be one function that determines what content should appear on the page, and another function that injects that content into an HTML file, probably with Template::Semantic or something similar.
(Long-term, I'd like to try making a more modern-styled version of this site, and slowly doing this would be the first step to having a JSON API.)
Yes, please! The current implementation is extremely fragile, so I would suggest making very small, incremental changes. You might also be interested in the work on the calcalc branch that I'm determined to merge one day.
For regression testing, you might be interested in the scripts in regress directory.
Is that branch actively developed? The last pushed commit is one year old.
I haven't had time to work on it recently, but it hasn't been abandoned. The present difficulty is that it requires a change to the data-file format. I started doing it manually, but I can't keep up with the changes on master; when I get time, the next thing I'll do is to automate the change to the files so that I can do it atomically. Pull requests are always welcome, but if there are people interested in working on that branch, it might be helpful if I were to write some documentation first.
Do you think it would be a better idea to do a change like this against master or calcalc?
(Thinking mainly of merge issues own the line)
master would be better. calcalc doesn't really touch the presentation logic (such as it is!), so I would expect minimal merge pain.
Thank you: that would be very welcome. If you're still interested (sorry for my delay...) I can document the required transformation. The essence of the change is that separate offices on a single day need to live in separate files.
@osoftware I tried to contact with @gregordick, with no success. I can suggest reading this wiki page: link. I don't know if it's still valid, unfortunately. I'm sorry I can't help more. I don't want you to remain without any answer.
I think that adding well-thought-out class names to the HTML output (in the spirit of semantic HTML) could go a long way towards making the output more machine-friendly. We could then bolt on an adapter to convert the output to any format we like.
