The-H

Hello.

Inserting a new message, the other messages update to remove their "edit" buttons.

And when we delete a message, the edit buttons for the post above it may be restored

This is all done very inefficiently at the moment, perhaps even worse than simply reloading the whole page (I'm not sure how much back and forth is going on).

The code which does it all is _very_ ugly. I do not know rails in the slightest. I do not understand the framework. I do not get the whole "MVC" thing. I'm trying, but I just never know where things are supposed to go when two views use the same partial, but that partial requires come mucking around with data, and the data doesn't fit nicely into what I'd consider the "model".
Meanwhile, I need to figure out how to style things for the spokesperson. Traditionally I've been using the exact same layout as the Post, but in MVC, I have no idea how to do that, since the spokesperson's post is not a real "Post", it's just a message look-alike.

And now there's a "Login" button. Of course, without a "I'm New!" button, it's pretty useless.

I've added a test gelf. This won't be used in the main site, but I'll use it for testing out the code.

The dropper probably shouldn't use AJAX.. no reason for that.

And now it doesn't.

New user creation is enabled, but don't get too attached to it. The database will be re-initialized frequently while testing is going on.

Validations are working, but I need to work out the spokeperson thing for error messages.

OH NOES

spokesperson worky now

threads, boards, preferences, cookies, pagination, resuming the current action after a login, marks, indexes and editors for gelfs/authlists/banners/borders, and not-sucking aside... I need to come up with a way to store gelfs in some sort of easy-to-manage package which can then be loaded easily into rails. The main svn repos should remain free of such things, but ideally an svn:external, a rake command and no additional work would be enough...

The development log says this page takes seconds to render, spending the largest single chunk of time in the border controller. Changing the border controller into a no-op didn't change that, so it may be related to overhead due to some code I wrote not knowing who-is-supposed-to-call-who. I'll change most of the border controller into a helper and see if that helps any.

Moving the border calls, the message calls now show up as taking the longest. Which may just be because the border calls aren't being tracked, the message calls now being the ones which call the border helper.

The border itself is currently hard-coded as using the picborder for everything. I intend to clean that up when I add preferences.

Cached some things, added some explicit JOINs, still a lot slower than the PHP version.

Note to self: work on the H a lot more because I love dreddnott.

that doesn't sound like good news at all!