Open skalee opened 4 years ago
skalee
commented
4 years ago We could also instantiate that collection in Geolexica similarly to what we did with concept collections in cc48a99114db400a28eab20b660bfa30fccc7c5c. But for some reason, this isn't working in case of that collection, I have no idea why.
Anyway, I'd rather remove that collection. Doing things in the other way they are supposed to be is often problematic, especially in Jekyll.
ronaldtse
commented
4 years ago @skalee FYI there is some effort from @strogonoff to generate the Geolexica site using Glossarist via a react toolchain. Perhaps we should start migrating our efforts there?
skalee
commented
4 years ago I am already convinced to migrate away from Jekyll at some point. It is good for blogging or landing sites, but not necessarily for sites like ours. Extracting common stuff to building blocks is difficult, writing tests is difficult (in fact, we have almost none of them, and rather than relying on them I'm running diffs to spot differences between old and new), documentation is confusing and incomplete, and more.
From quite some time, I am thinking what feature set we need, and I have a more less clear vision already. I am considering either migrating to another tool or implementing a new one.
We don't use plenty of Jekyll features, so writing a new one is a considerable option. Nevertheless, there is a number of problems which need to be addressed, including processing SASS, rendering templates, composing pages from layouts and partials, or shadowing generic templates with ones dedicated for particular sites. I hope many can be taken from Rails, especially Asset Pipeline, maybe Action View which is responsible for rendering, and some of view helpers. I hope that some testing helpers can be imported too. I haven't prepared any proof of concept however, so it's difficult to tell how much work is really needed.
Perhaps we should migrate to another existing tool. Nanoc is another generator written in Ruby designed around a different philosophy than Jekyll is. It is likely to match our needs, but on the other hand it seems over complicated, at least at the first glance. I need to dig into documentation before telling more. Anyway, it should be far more flexible than Jekyll.
Integrating site generation into Glossarist that you mentioned is another promising idea. I suppose it may enrich Glossarist application with some nice features like live previews. Maybe this will help in creating Geolexica mobile app easier too, if such app is desired and if Cordova-like tools are acceptable. On the other hand, site generation will require 3rd-party tools like LaTeXML or AsciiDoctor, which in that case would have to be bundled with Glossarist, which may cause difficulties on some platforms. Furthermore, site generation requires things like RDF or TBX-ISO-TML generation, which would have to be implemented in Glossarist. But again, this can be a feature in context of live previews.
However, with all above being said, Jekyll issues are manageable, and I've got used to them. Sometimes bit more configuration is needed, sometimes we have to be flexible, but so far it was never a big issue and I doubt it will ever be. I am more worried about breaking something accidentally due to insufficient testing. Also, diff-based testing is potentially quite time-consuming, depending on situation, but though Jekyll is an obstacle indeed, this also isn't a thing which can be improved easily just by switching to another tool.
Perhaps this should be discussed in a separate thread.
Geolexica defines
pagescollection, which aggregates various meta pages. This leads to many problems:pagescollection must be explicitly defined somewhere)Pages collection should be removed.
However, we specify page permalinks as
/:page/via that collection configuration. We need to preserve these setting somehow, and it may be non-trivial the other way we do. Usual Jekyll things…