Release 0.1.0 Tagged With Many Changes

Core is beginning to become stable.

I am happy to announce v0.1.0 of Dr. Henry. There have been many changes in this release, but the core structure of things is now at the intersection of where I want it, and what is possible within the current limits of GitHub Pages, and should stop being a moving target for anyone wanting to actually make use of it. :smile:

Read on to learn more about the features of the release.

The theme “API” has seen a lot of rework in the internals, its cleaner where it needs to be, which is working with the theme templates, and ugly where we can hide it in the setup function. Rather than do this:

{% include theme file="theme_bit" %}


You now use:

{% include {{tt_theme_bit}} %}


The disadvantage to the old method is that it required a double-include, which doubled up depth of include on everything, and made the possibility of using key=value as template variables impractical. It also required recalculation of theme include path every include.

The new method is not all rainbows and unicorns either, but it is better. The setup file now pre-calculates all theme paths into variables with the tt_ prefix to the item name, and you include based on those. It means pre-calculating things that might not be used in a given view, but it resolves most of the issues of the prior method, and the overall calculation comes down some for some views. It would be much better if we could simply build hashes on the fly, resolve it lazily and memoize the result, but the template environment will not allow this.

How asides get configured had to change a little, as they can not directly construct a tt_aside_name variable based on the config, so we have a switch block for now.

After all that was done, a lot of theme refactoring was done. As the initial PoC was put together, there were a lot of overriden theme items, some of which just were not necessary, and in other cases things were pushed around to get structure into the layouts, such that the functional elements could be more general.

And in some cases, useful aspects were pushed down to the core theme so that all themes could make use of them. One such decsision was that to put Font Awesome as a commonly available asset to themes. This was used in Octofound, which one of Dr. Henry’s themes are based on. It’s been pulled out and updated to 4.1, and all themes make some use of the many icons that Font Awesome provides.

The last major feature of this release is the start of a structured header, and JS/CSS resource management. At this point, the contents of the HTML header nearly universal for all themes. This is made possible by pushing JS/CSS expressions into the theme configuration. Because of this, the jekb theme, which previously only supplied a head template for adding it’s custom CSS, now doesn’t include any theme templates, as it can add the customizations via the configuration.

This is a sample of the header javascript as currently found in the foundation5 theme:

js_top:
  - url: /assets/themes/foundation5/js/vendor/modernizr.js
  - url: /assets/themes/foundation5/js/vendor/jquery.js
  - url: /assets/themes/foundation5/js/vendor/fastclick.js
  - url: /assets/themes/foundation5/js/foundation.min.js
  - inline: |
      $(document).ready( function(){ $(document).foundation(); });


The items are processed in order, that inline could be in the middle of the URL items, and it would be placed in that manner.

This is just the start. As you can see, the section above is js_top, but js_bottom is not yet implemented. It should be possible for pages to express additional items, and they be included, and this is also, not yet implemented. But you can see where this is going.

Besides all that, just small cleanups as we go, nothing of note really.

So the usual warnings that everything is due to change imminently and often I think are less of a concern for now, I do not plan to make any radical changes to the internals from here, until GitHub Page makes Jekyll 2.0 available to us.

Share and enjoy!

@jhohertz