search

DivinumOfficium / divinum-officium

The Divinum Officium Project: Traditional Roman Missal and Breviary Texts
http://www.divinumofficium.com/
309 stars 194 forks source link

Separate Logic from Display #626

Open edbrannin opened 7 years ago

edbrannin commented 7 years ago

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.)

gregordick commented 7 years ago

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.

osoftware commented 7 years ago

Is that branch actively developed? The last pushed commit is one year old.

gregordick commented 7 years ago

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.

edbrannin commented 7 years ago

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)

gregordick commented 7 years ago

master would be better. calcalc doesn't really touch the presentation logic (such as it is!), so I would expect minimal merge pain.

osoftware commented 7 years ago

I would gladly help with creating a converter to the new data format.

gregordick commented 7 years ago

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 commented 7 years ago

Still interested.

osoftware commented 7 years ago

bump

DLakomy commented 7 years ago

@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.

ewcole commented 4 years ago

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.