fabsor's sandbox: Hyde

Hyde is a pluggable content generation system, with focus on generating Drupal content to HTML pages. The name comes from a popular similar system, Jekyll.

Why?

The time when a browser was just a dumb client and servers had to do all the heavy lifting when it comes to business logic is over. Modern browsers today aims to be application platforms onto which you can run your code, and there are some pretty impressive demonstrations of this in many places today.

Drupal and systems like it are currently operating the old school way: The system handles everything, content administration, the actual rendering of the content, and any other interactive functionality that goes on around it. This is a complicated system, and it relies on several pieces of software to deliver content to a user: We have to have at least a web server, some middle-layer application and a database involved in every request.

A great blog post describes some problems with this approach, and I agree to some extent with what they are saying. They are missing one big point however: Creating a big amount of content in a big organisation is more complex than just editing a document. A system for building a web site in any medium size organisation needs to be able to handle things like roles and permissions and different user accounts, content moderation and approval processes and so on. This is where Drupal shines in my opinion, and I would definitely not want to replace it with any home-made solution.

Hyde is an attempt to become a middle ground between walking away completely from CMS systems and gaining more control of the actual output and how we work with interactive functionality on our web sites.

The approach

Hyde tries to generate HTML content out of the content of your Drupal site. It does so by providing several concepts, described below.

Renderers

A renderer exposes a set of templates through a template engine like twig or mustache. The renderer is very simple, it's just a wrapper around an existing template engine. The current focus is on the twig rendering plugin, since it's a nice and secure template engine that is suitable for our needs.

Processors

Processors are used to process data in CTools contexts to make them easier to work with inside of a template language. It's a lot like a preprocess hook in the Drupal rendering system.

Iterators

An iterator iterates over Drupal content (such as entities). The iterator is basically fetches a set of data. Each item that can be iterated over is described as a CTools context. The iterator is configured to use a particular renderer, you can use CTools relationships and contexts to add more contexts that will be exposed to the renderer (Like views), and you can add processors that will process the contexts that are available during the rendering.

Site

A site is a collection of iterators that forms one individual export of content.

Workflow

The system is meant to work like this:

1. You configure your node types, views and so on.
2. You create a Hyde site for exporting the content to HTML.
3. You create templates in for instance twig, that will represent the markup of your site.
4. You use drush to export your site as HTML pages.
5. Deploy anywhere!

Any dynamic functionality like comments and so on can be provided by using third party services like Disqus and google analytics. More specific functionality can be provided by creating web services that integrate with the system.

Status

This is still in really heavy development. Some of the concepts have been ironed out, but there are several pieces still missing. This sandbox will contain the status of this pretty big undertaking, if you're interested in helping out, post an issue!