Adding more Oomph

So far we've created an exporter that produces an index.html file with some content and also [screen name].html files, each representing one specific screen of the exported project. But there are still some remaining tasks ahead of us:

  • The index.html file needs proper content

  • Produced HTML code is invalid, missing header and body tags

  • Pages could use a bit of styling

  • Backing up and publishing our new exporter for others to use

Let's finalize the content first.

Creating proper content for index.html

The index page should present a list of other pages derived dynamically from the project, but it currently only shows some static dummy content. Open the blueprint editor for the index page and copy/paste the following blueprint code:

{* Fetch data about all screens in project *}
{[ var screens @project.allScreens() /]}
{* Create screen menu linking to subpages *}
<h1>My Humble Portfolio</h1>
<ul>
{[ for screen in screens ]}
<li><a href="./Screens/{{ screen.name }}.html">{{ screen.name }}</a></li>
{[/]}
</ul>

Let's look at what this Blazar code does. First, we request data about all screens using the @project.allScreens method and then iterate through it using for. This will construct a menu with a dynamic list that will change and be different for every project you open, or as you add or remove screens in a given project.

Run the exporter and open the index.html page in your browser. You are now able to move around in your portfolio!

Our portfolio website now has a table of contents

Styling every page

To style all the pages, we need to add a header and put some CSS into it. Pretty simple task, except we want that header to be shared across all pages that get exported. This is obviously a good practice - anything we need to change down the road we can do from just one place.

But how do we share the content between blueprints? With another blueprint, of course.

Navigate into blueprint manager and create a new blueprint, naming it "Header" - or however you want. This blueprint will contain a definition that will be used on all the pages.

Making the header blueprint, just like before. Pay attention to highlighted fields

This time, we get to use the Blueprint ID. Blueprint ID makes the blueprint available everywhere in the code context, giving us the ability to reference it and "include" it inside any other blueprint. Group can be used to separate the blueprint from others in the blueprint list, keeping things organised.

Open the blueprint code and copy/paste the following HTML code:

<!DOCTYPE html>
<html>
<head>
<title>My Portfolio!</title>
<style>
h1 { color:#666; }
a { color: #328fa8; text-decoration: none; }
ul { list-style: decimal; }
body { margin: 100px; font-family: Arial, Helvetica, sans-serif; }
</style>
</head>

As you can see, there is no dynamic blueprint code. That is just fine - blueprints can be used simply to store a piece of static content for later use - which is ideal for configurations, static definitions and similar tasks.

Now we just have to use the header. Close the blueprint editor for the header blueprint and open the index blueprint. Insert the following blueprint code at the beginning of the file:

{* Inject header from different blueprint *}
{[ inject "support.header" context self /]}

We use the Inject flow which allows us to use any blueprint and simply insert its interpreted content inside another blueprint. As you can see, with just one line, we have added the content of the entire header into our index blueprint.

Inject flow takes an additional parameter called context. The full syntax is inject [blueprint] context [variable] and variable simply represents data that can be passed into the injected blueprint.

For example, you could send the title of the page to the header, and then use this data when rendering it.

Index blueprint with injected header code

Note that we also added a <body> tag to the blueprint, so the produced code is valid. Repeat the same thing with the Screen blueprint as well and you'll see the same header used on all the pages.

Screen blueprint with the same header code as seen on the index page

Testing the exporter

The entire exporter is now ready! Let's do a test export run, selecting all screens and selecting the destination directory. The index page now looks much better, with some colors and proper linking to detail pages - which are styled as well. If you have followed the entire tutorial so far, your result will look like this:

Index page, all styled and pretty
And a detail page, pretty as well!

Congratulations, you've built the entire exporter. There are tons of things that you can do now - move styles into a separate style file, render content of the page properly based on its actual, imported structure, add layout, add animations, use the internal navigation of Supernova instead of a simple list, etc. Only your imagination is the limit.

This tutorial only scratches the surface of what is possible with the exporters. In the following chapters and tutorials, you'll learn all of its superpowers, including some really wild ones like the ability to merge code that you write by hand with code auto-generated by Supernova.

Yes, that's right! Feel free to pick any chapter, or jump straight into examples section if you like to learn this way.

But before you go to it, we suggest reading one more chapter - how to back up your exporter and make it available to others so you can build complex automation pipelines - as an individual, or with a team.