Producing Dynamic Content
Now that we have the index.html being produced (albeit with only dummy content), let's move on to creating a blueprint that will define content for each screen.
Start by creating a new blueprint again and filling it with whatever information you like.
Open the blueprint editor and copy/paste the following blueprint code:
{* Fetch data about the screen *}{[ var screenData @project.screenById(screenId) /]}{* Generate HTML code for the page *}<h1>{{ screenData.name }} Detail Page</h1><p>Page Content</p><a href="../index.html">Get Back</a>
The blueprint first fetches the data about the currently-exported screen from the Supernova Universal Model using the @project.screenById function and then uses the name property from the result in the page header.
Note that if you paste the code into the editor, it will show an error in the editor console saying that screenId is not defined. This is because, by default, invocation is set to once and doesn't provide screenId to the blueprint. You can fix this by changing invocation to once per screen , which will define screenId in the current context and the error will disappear, generating proper output in the interpreter window.
Note that you can simulate how the output will look for every screen by changing exported screen from First available to any specific screen in the currently selected project.
This changes the screenId definition to the specific screen, and the generated output will change accordingly if the blueprint uses it. This is only a simulation of one scenario, for test purposes, of course - the real export will run with all the screens, one by one.
As before, if you run the exporter, the file(s) will not show up, but you now know how to fix that - by adding the blueprint to the exporter output mapping.
At the beginning of the tutorial, we established the goal of exporting all screens to differently named files. The result should look like this:
/root/index.html/screens/welcome.html/login.html/signup.html...
With the current configuration, we are able to create index.html and fill it with the static content. But how do we provide a dynamic file path based on the name of the screen? You guessed it - blueprints for the rescue.
Navigate to the mapping section once again and create a new entry, filled with the right information. This time, we want to invoke our Screen blueprint when export runs, so select Screen blueprint from the popup.
As you can see, the generated file path still shows the default path to root/file.txt. The objective here is to show the correct file path by writing a blueprint which will "render" it.
Click Edit Path Blueprint and copy/paste the following blueprint code:
{[ var screenData @project.screenById(screenId) /]}Screens/{{ screenData.name }}.html
The code above once again fetches the screen data, and constructs the file path which defines both the folder in which to put the files and the name of the file itself.
As you may remember, you changed the invocation type when generating content for the screen. The path blueprint, however, doesn't offer a choice of invocation type.
This is because the invocation type is tied to the code blueprint and the path blueprint always follows its configuration.
When you return to the mapping configuration, you'll see that the path is now changed to properly represent our intention:
Run the exporter with the latest changes, and you'll see many files generated this time, exactly replicating our expected structure.
You can also try opening the detail screens in your browser - clicking "Get Back" will get you to the index.html , validating that we produced real HTML code. The only thing remaining now is to add a bit more design to our portfolio and to create a better index.html file that will serve as a proper table of contents.
