convert to Jekyll / yaml
phonedude opened this issue · comments
This still needs to be updated to be a proper Jekyll / yaml driven page. I hacked the current version together to get ready for the 2021 Research Expo.
@phonedude I started an effort toward this in early November 2020, available at https://github.com/machawk1/oduwsdl.github.io , visible at https://machawk1.github.io/oduwsdl.github.io/
@ibnesayeed took a different approach in his PR #26 but I think there is some usefulness in using Jekyll collection, as I have in my fork.
@machawk1 Jekyll collections feature is great for multi-page sites. In this case, it is primarily a single page application. With the collection approach, one would need to create a file for each entity, which will be rendered as a separate page (in addition to corresponding index page).
The advantage of data files over collections in this case is not just fewer files, but the data file can be used in other places as well and are cleaner to maintain. Also, if we do need to generate pages for each entity, there are Jekyll gems (like, https://github.com/avillafiorita/jekyll-datapage_gen) that will allow us to do that.
Roger re: Jekyll. And thanks for the alumni demo. And agreed re: local copies of twitter avatars.
And agreed re: local copies of twitter avatars.
Should the avatar file names correspond to their Twitter handles or actual names? Using Twitter handle for avatar file names would be simpler, but will break (unless we have fallback in place) if there are people without a Twitter account associated. Using slug of their names is another possibility, but name collisions would be tricky to address.
those without twitter links are using the default twitter image: https://abs.twimg.com/sticky/default_profile_images/default_profile_400x400.png
I could go either way on the filenames -- hashes are certainly easier, but over time we'll end up with many files that we'll have to click through to know who they are/were.
so far, no name collisions within WSDL ;-)
those without twitter links are using the default twitter image: https://abs.twimg.com/sticky/default_profile_images/default_profile_400x400.png
Yes, I realized that and that's why I saved it as ssets/images/avatars/default_profile.jpg and added the following template in PR #27 that handles the fallback in case the twitter_handle property is missing.
<img src="assets/images/avatars/{{ alumnus.twitter_handle | default: 'default_profile' }}.jpg" width="100" /></div>I could go either way on the filenames -- hashes are certainly easier, but over time we'll end up with many files that we'll have to click through to know who they are/were.
Hashes are cleaner when the input source has messy characters, but the downside of hashes is, they do not prevent collisions if the source collides and as you said, they are opaque when it comes to dereference them. If the collision was not an issue, we could have just used the slug of names (that would downcase everything and replace non-alphanumeric characters with dashes). I opted for Twitter handle as it is already safe for file names, is unique, and the source of the profile picture is currently tied to Twitter anyways. It will be tricky if we were to support the case where someone does not have a Twitter account, but we want to use a custom picture for them anyway (a problem that we do not have right now).
@Tarannum123 your recently merged PR #28 has leftover commented lines of previous markup, which should be removed now.