Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate Logic from Display #626

Open
edbrannin opened this issue Nov 2, 2016 · 11 comments
Open

Separate Logic from Display #626

edbrannin opened this issue Nov 2, 2016 · 11 comments

Comments

@edbrannin
Copy link

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
Copy link
Contributor

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
Copy link

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

@gregordick
Copy link
Contributor

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
Copy link
Author

edbrannin commented Nov 17, 2016

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
Copy link
Contributor

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

@osoftware
Copy link

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

@gregordick
Copy link
Contributor

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
Copy link

Still interested.

@osoftware
Copy link

bump

@DLakomy
Copy link
Contributor

DLakomy commented Jun 23, 2017

@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
Copy link

ewcole commented Aug 13, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants