Hello Pluto!
Given the multitude of scenarios and possibilities, a dead simple Hello World is not particularly instructive. To be a little more useful, we make our Hello World a little more far out than usual. We go to Pluto…
There’s many scenarios possible. We are just going to pick one, and get on with it. Here’s the bunch of assumptions and choices that we adopt for our Hello Pluto! example site:
- We use Gizmo(QP) Directory-based traversal (the default).
- We run a Durus database server, locally.
- We initialize the database, creating the user pluto with password pluto.
- We make an index page that is accessible anonymously.
- We make a second pluto page, accessible only to authenticated users.
- We provide a form-based login facility.
- We use EvoqueTemplating and supply a page template for the site.
- The site template defines the breadcrumb trail for every page.
- The site template defines a hierarchical navigation menu for every page.
- We deploy under QP’s built-in web server.
- We also deploy behind Apache, using SCGI and tell SCGI to manage up to 3 child processes.
The source for this demo site are included in the gizmo(qp) distribution at gz/demo/hellopluto. Also, for convenience, an instance of this demo site is deployed at http://pluto.gizmojo.org/.
Site source code
Gizmo(QP) sites are QP sites, meaning that they are defined as a python package that implements a slash module, that in turn provides definitions for a SitePublisher, with a site configuration dictionary, and a SiteDirectory class. Here then is the file hellopluto/slash.py where hellopluto is a python package located somewhere on the qp sites search path.
Site page template
Note that this specifies only our essential template — it has no <head> and <body> elements. The resulting document is however a properly formatted html document, generated by the EvoqueTemplating.
Also, the CSS styling for the site is not shown here. To view it, see the source code in the distribution for this demo.
Site management and deployment
To launch the site, we use the qp command, that is the management tool provided by QP itself.
This will also initialize the durus database, that unless we specify differently is placed at hellopluto/var. Note, it expects that the var subdirectory has already been created. We can now view the site by loading the following URL in a web browser:
To get a running view of the server logs, or to view status, or restart or stop the site, we do:
To access the Apache/SCGI deployment, we would need to define an Apache VirtualHost, with something such as below.
If the site had any static files, e.g. /images/
, that we would prefer to serve directly from Apache, bypassing SCGI altogether, we can optionally add Location or LocationMatch directives.
Other variations
- To not run a Durus database server we make our SitePublisher inherit from Publisher and not specify the durus_address in our site configuration.
- To not deploy under QP’s web server we just not specify http_address in our site configuration.
- To not deploy under Apache/SCGI we just not specify scgi_address in our site configuration.