The core and auth modules are the only mandatory modules required to run triki. They provide the core functionality required to add, edit and render web pages.

The core module takes care of the following:

On startup, the core module will initialise itself and all other modules. It will find the file containing your graph database and reload this into memory. Finally it will initialise the web components and then listen for HTTP page requests.

When a request is received, the following three steps happen:

Check Authorisation

The auth is first called to ensure the user is permitted to view the page requested. All pages are assigned a restricted property which defines the user group that is permitted to view the page. If the page is restricted to group public, then it is open to anyone to view.

If the page is assigned to a group, then user must be part of the group to view the page. In reality, the permissions are assigned to graph nodes but as shown below, nodes are mapped to pages.

As shown in the auth page, the nodes that the page references are also permissioned. This means that how is a page is rendered may vary depending on the permissions of the signed in user.

URL to Node mapping

The graph backing your triki website data will consist of many inter-related nodes. In order to represent each of the nodes as a web page there is mapping between the web address and the node "address". To achieve this every node is given a prefix which defines the path to the URL followed by a node name. With both of these, there is now a simple link between the address of the node in your graph and the web address.

Also, all nodes in your graph (and therefore in your triple store) have a default root address that is locally resolvable and defaults to http://localhost:9090. This can be changed if necessary.

Example: Mapping nodes to web addresses

AddressURL
Graph nodehttp://localhost:9090/blog/summer-holiday
Webhttp://www.yourwebsite.com/blog/summer-holiday

Dynamic page rendering

triki is not a traditioal static page generator, every page is rendered fresh when requested by a browser. Once the address of the node has been found, it is passed to the renderer to generate the HTML page.

The rendering uses a rock solid templating tool that has been around for many years called StringTemplate. This is a simple but powerful templating engine that allows a blog page (for example) to render the basic content from markdown and the data elements of the page, like who who created it and when it was created.

For more complex node models with more properties, it is just a case of referring to the node address correctly in your site.stg templated file. Related nodes can also be rendered, for example a Blogs index page may want to show a list of titles from all BLogs, this is just a related node in the graph to easy to achieve.

Example: A blog has following triple showing blog title:

    root:blog/summer-holiday
          dc:title 
            "Summer holiday 2019"
    

This would be reference from the page template using:

    $props.dc_title$