Open crowbot opened 9 years ago
Quick search on Confreaks finds http://confreaks.com/videos/2554-goruco2013-microtalk-building-a-theme-engine-w-ruby-mustache
I think we should dogfood this as much as possible by using our own interface for anything that isn't core functionality (e.g. comments on requests, public body stats page, etc)
Need to look in to this more, but the Two Step View Pattern is an interesting idea.
https://practicingruby.com/articles/sustainable-foss-quality cites RDoc as a good example of "a good library to look at for examples of what this technique has to offer.", and also provides a real-life example of an extension the author wrote for the library.
This (or the lack of it) could well be a key factor for re-users not upgrading to later versions.
a well-defined extension API can greatly increase a project's stability.
– https://practicingruby.com/articles/sustainable-foss-quality
One of our re-users specifically cited their theme as an issue preventing them upgrade
3) I use a custom theme which I plan to drop.
http://www.quesabes.org/ also required theme updates – not sure how much, but presumably more than trivial?
Recent improvements versioning system and deprecation notices should also help towards this.
Currently theming works by allowing the theme to override any code or template in the core Alaveteli codebase. This allows for a lot of flexible behaviour alteration by themes but means that whenever core Alaveteli code changes, it could be breaking an existing theme - we have no control over, or expectation about, what code people might have overriden or hooked into in their theme. A defined interface in the form of callback functions that the theme can use would allow core code to change more easily. The downside is the loss of flexibility in what behaviour themes can change.