In order to expose a convenient API, it's unfortunately necessary to
lean on Go's interface{} quite a bit: in reality we only accept a
handful of types at each call site, but it's impossible to express this
using the type system.
Prior to this commit (as well as the ParsePattern commit), I exposed all
of this type information in the form of an enormous comment on web.Mux,
however this was pretty gross. Instead, let's use "vanity" type aliases
for interface{} to provide documentation about which types are accepted
where. This will hopefully make the API documentation easier to skim,
but doesn't affect any existing uses of Goji.
This commit also clarifies a couple other parts of the documentation.
This is a major breaking change to web.C, the Goji context object. The
Env key has been changed from a map[string]interface{} to a
map[interface{}]interface{} in order to better support package-private
environment values and to make the context value more compatible with
golang.org/x/net/context's Context.
Since strings support equality, most existing uses of web.C should
continue to function. Users who construct Env by hand (i.e., by calling
"make") will need to update their code as instructed by their compiler.
Users who iterate over the environment will need to update their code to
take into account the fact that keys may no longer be strings.
The "dryrun" parameter on Pattern.Match was kind of ugly and made for an
exceedingly mediocre public interface. Instead, split its functionality
in two: the previous "dryrun" behavior now lives in the Match method,
and Patterns now actually mutate state when Run is called.
The code on the backend is of course still the same (for now), but at
least the interface is a little nicer.
This change replaces a bit of API surface area (the Sub() method on Muxes) with
a slightly more expressive pattern syntax. I'm mostly doing this because it
seems cleaner: the "*" gets to take on a meaning very similar to what it means
in Sinatra (without growing regexp-like middle-of-a-path globbing, which sounds
terrifying and not particularly useful), and we get to nuke a useless function
from the API.
Package web will now add a key to the environment when it fails to find a
valid route for the requested method, but when valid routes exist for other
methods.
This allows either the 404 handler or a sufficiently clever middleware layer to
provide support for OPTIONS automatically.
Add tests for both string and regular expression patterns. Also, reimplement
regexp.Regexp.Prefix() on top of the raw regexp/syntax representation, so we can
get a little more information out of regexps:
- Whether or not the regexp is left-anchored (at the beginning of the string)
- What the prefix of the regular expression is, even for left-anchored
expressions.
We do this by running the regular expression instructions ourselves, more or
less cargo-culting the original implementation from package regexp/syntax.
Unfortunately it's ~impossible to make this abstraction non-leaky, because the
regexp package doesn't give us information about whether or not it was
constructed using POSIX or Perl syntax, for example, or if the longest-match
setting was applied.
The upshot is that regexps are now probably pretty performant-ish. Maybe. (I
haven't actually benchmarked it).
They say that every programmer builds a web framework at some point. This one is
mine.
The basic idea behind this one is that I wanted a Sinatra for Go, and I couldn't
find one anywhere. Furthermore, net/http is in many ways really close to what I
want out of a Sinatra-in-Go, and many of the frameworks I did find seemed to
reinvent too much, or were incompatible with net/http in weird ways, or used too
much questionable reflection magic. So long story short, I wrote my own.
This implementation is only half-baked, and among other things it's missing a
whole lot of tests.
Carl Jackson
SatoShun
Coda Hale