I like the black-on-white asthetic, so let's make the dropdown menu do
that. I pulled this code from
https://github.com/twbs/bootstrap/issues/9588
It works great now that I'm processing my sass
I'm going to add the SASS in a bit. For now I just want to get these
removed to make room for where I'm going to be putting the SASS
post-processed output
I'll probably use it. Fairly certain. It looks nice either way.
This breaks up the main layout to 'things with the navbar' and 'things
without' and uses inheritance to make it all work out nicely. I also
added my first static asset which assumes nginx is properly configured
to serve up the file rather than doing it through vanth
This removes some of the logic associated with using JSON based
authentication in favor of the simpler and more built-in form based
authentication that I had originally gotten working. This requires no
JavaScript from the browser, which is its own reward
I've decided I want this application to be a progressive enhancement
application. That means that I'm not going to keep dealing with the
insanity that is Javascript bundling and transpiling and building the
entire UI in JS. I want to believe I can treat the web the way that it's
been designed for decades - as a document platform with enhancement
capabilities rather than as an emerging VM
This only adds one institution that I care about, AFCU, but could be
extended to use the data from ofxhome.com. I downloaded the data from
them but found two problems. One, they work in XML, which I don't feel
like parsing, but two and far more importantly, they provide the second
piece of data I need, the routing number for the bank. That sucks. So
it's likely that if this project does well we will have more data than
them.
If we don't reorder this logic then we'll never set up the user's
information so that GET /session/ has the data it needs to show the
session information.
This commit adds setting the content of the current user from the
session cookie the user sends back and forth. That means we can actually
pull out the session data for use when handling requests. We can also
create new sessions and set up the session cookie
We're just testing that the about route works at all. We aren't even
testing that it does anything. But this represents wiring together a
bunch of things to get tests working including configuration
specifications, DB connections, table definitions, the app itself, etc
This doesn't do much - it'll authenticate any username and password. But
at least it will show me when a user is logged in and when they aren't,
which is useful to start figuring out the workflow for sessions
I took a stab at a reasonable schema just to get started. For now I want
workflows that are working. I'll pound the thing into the correct shape
in time
Eli Ribble