How things get done in Djet

Djet is a very extensible PSGI application, with database controlled navigation.
Djet is a PSGI application, so any Plack server can run it. Currently I'm satisfied just using starman behind an Nginx frontend for my own business, but any combination will do - people have different preferences for their web servers.

I love the fact that I don't have to worry about sessions, image handling, log, debugging, etc. Plack Middleware does it all.

But there is still a little work to be done after that. I'll try to explain how Djet does it.

Now, the job of a web server is really a simple thing. Or should be. A client (usually a web browser) sends a request, and expects a reply. In Plack world even the reply is simple, it's just an arrayref looking like this: [ $status, $headers, $body ].

Simple, eh? Well, except that the status (and headers) depend on a lot of hints and clues offered by the request
Colossal Cave
One of the clues, if you can call it that, is the path. The path is central in Djet. It's used by Djet::Navigator to determine which Djet::Engine to use to produce the reply.

Djet::Navigator looks up the requested, or the closest, path in the database, and sets these attributes
Let's say that the path is /where/do/you/want/to/go/today and that there are nodes covering until the "go" part, then the result will be
Note that the rest_path is the leftover from the path, NOT the uri parameters. They are treated normally, using Plack::Request.
OR, if the access control settings prevents the user from accessing that path, the result will be set to redirect the user to a login page.

The basenode points to a Djet::Engine. A Djet::Engine is a Web::Machine (Well, really Web::Machine::Resource) object, that determines what to reply. Web::Machine ( is an amazing, albeit underdocumented, module, that guides you through the maze of twisty little passages, all alike, shown in the image above.

There are a few Djet::Engines already with more to come. But this is also the main extending point in Djet. It's impossible to foresee every need that everybody will have anytime. Instead, it's possible to write a custom engine for any specific purpose.

There are Admin engines to update basetypes and datanodes, blog, contactform, news and search engies to handle specific areas. There are engines for ordering products, for login and logout, and there's a default engine that just presents the node's data to the templating system.

Latest progress

I'll end this blog post with an overview of what has happened since last time.




Fields in bold are mandatory
Email Address