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
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
- Basenode is the node corresponding to the requested path
- Datanodes are all the nodes found from the "top"
- rest_path contains whatever didn't match any path
- result is a plack response and is set if the navigator decides to take a detour
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
- basenode: /where/do/you/want/to/go
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 (https://metacpan.org/pod/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.
I'll end this blog post with an overview of what has happened since last time.
- Removed my own, very basic HTML5 editor. No idea having to maintain yamp (yet another moving part). Finding a replacement proved harder than I thought. I ended up with cleditor though it's not perfect. Especially it doesn't handle file (image) uploads out of the box.
- Added a flash feature, a little like the one in Catalyst.
- Added a way to extend the individual basetypes. This is way more cool than it sounds, it adds control to (almost all) aspects of the system.