Latest Zmpl provides `template.renderWithLayout(other_template, data)`,
allowing a template to be renedered within another template.
Create layouts in `src/app/views/layouts/` or use
`jetzig generate layout [name]` and set `pub const layout = "name";` in
each view file.
Runs a development server and auto-reloads when changes are detected to
files.
Note that a "change" is just an mtime update, Zig does a more
intelligent change detection so avoids unnecessary recompiles, so the
server reloads very quickly.
Views are copied to zig-cache, meaning that any files in `src/` are not
available for `@import` by default. Copy all .zig files from `src/` into
zig-cache so that relative imports work as expected. This also removes
the need to specifically copy views into zig-cache as the full tree is
now present.
Also fix a bug in static route fallback - remove superfluous underscore
so static routes with non-matching params render default HTML/JSON
content.
Offload as much work as possible into new `jetzigInit` function provided
by Jetzig's `build.zig`. This means that a new Jetzig project's
`build.zig` is now almost completely vanilla with the exception of two
extra lines:
```zig
const jetzig = @import("jetzig");
```
```zig
try jetzig.jetzigInit(b, exe, .{});
```
Latest Zig nightly now hits a panic, probably we have a cyclic reference
in the tree. We should fix this ASAP otherwise we risk adding tests
without running them, but for now this should get builds passing again
with latest Zig.
Latest update normalizes input by adding a terminating linebreak to end
of input stream if not already present, fixing an issue where parsing
finalised with content still present in the char buf. A warning is also
raised requesting a bug report if this occurs.
Allow custom functions with arbitrary signatures and avoid any issues of
trying to parse functions that are not Jeztig route action functions
(i.e. index, get, post, put, patch, delete).
Remove old bash script for setting up a new project, do everything in
Zig to make it platform agnostic and give us an easy place to add
scaffolding commands in future.
Andrew overhauled std.http to avoid allocations and put control of
connection + stream into hands of users. For now, do a barebones
implementation to restore compatibility, later we can do keepalive and
pipelining. For now, still getting decent enough performance the "slow"
way.
Relevant commit: 6395ba852a
Commit message copied here for posterity:
> Author: Andrew Kelley <andrew@ziglang.org>
> Date: Tue Feb 20 03:30:51 2024 -0700
> std.http.Server: rework the API entirely
> Mainly, this removes the poorly named `wait`, `send`, `finish`
> functions, which all operated on the same "Response" object, which was
> actually being used as the request.
>
> Now, it looks like this:
> 1. std.net.Server.accept() gives you a std.net.Server.Connection
> 2. std.http.Server.init() with the connection
> 3. Server.receiveHead() gives you a Request
> 4. Request.reader() gives you a body reader
> 5. Request.respond() is a one-shot, or Request.respondStreaming() creates
> a Response
> 6. Response.writer() gives you a body writer
> 7. Response.end() finishes the response; Response.endChunked() allows
> passing response trailers.
>
> In other words, the type system now guides the API user down the correct
> path.
>
> receiveHead allows extra bytes to be read into the read buffer, and then
> will reuse those bytes for the body or the next request upon connection
> reuse.
>
> respond(), the one-shot function, will send the entire response in one
> syscall.
>
> Streaming response bodies no longer wastefully wraps every call to write
> with a chunk header and trailer; instead it only sends the HTTP chunk
> wrapper when flushing. This means the user can still control when it
> happens but it also does not add unnecessary chunks.
>
> Empirically, in my example project that uses this API, the usage code is
> significantly less noisy, it has less error handling while handling
> errors more correctly, it's more obvious what is happening, and it is
> syscall-optimal.
>
> Additionally:
> * Uncouple std.http.HeadParser from protocol.zig
> * Delete std.Server.Connection; use std.net.Server.Connection instead.
> - The API user supplies the read buffer when initializing the
> http.Server, and it is used for the HTTP head as well as a buffer
> for reading the body into.
> * Replace and document the State enum. No longer is there both "start"
> and "first".
Create `jetzig.http.Response` when `std.http.Server.Response` is created
and delegate all management of `std.http.Server.Response` to
`jetzig.http.Response`. Using this internally means we use the same
internal interface for the `Response` as the user, which gives us things
like response headers management in views for free (user simply calls
`request.response.headers.append()` etc.).
