zmarvel / coffeespot Goto Github PK

I used wtforms for the user management stuff, and it worked out really well. Definitely going to be moving all the other forms on the site to wtforms as well.

This is pretty low priority. It will probably take a pretty good chunk of time.

It would entail storing some configuration, presumably in a table. This tells the application where too look for CSS and for templates. The relevant changed directory structure would probably look like this:

/static
    -> /1
        -> /css
            -> /style.css
        -> /img
            -> /xxx.png...
        -> /scss
            -> /style.scss
/templates
    -> /1
        -> /base.mako
        -> /home.mako
        -> /xxx.mako...

I think that's a little weird, though.

Uploading of the files for each theme through the interface has the benefit of supplying the application with the necessary information to load the files when the admin chooses to use this theme.

Really, defining a more modular theme interface would be pretty cool. Especially using scss, it would not be too complicated to provide a way to modify the theme from the admin panel. I somehow feel that storing this information in a db table would be kind of messy. I will have to think on this one.

Even though this is kind of a blog, blogs typically have a few pages, as well. It should be easy to store some pages written in Markdown. They just get their on db table.

I'm a programmer, this is for my blog, I should have syntax highlighting.

I can't see why it would be a bad idea to store the posts and pages in a separate table (or even a different column in the same table...?) after they have been parsed once. That is, parse them when they go in, but keep the Markdown around so it can be edited later.

Currently, when you try to view an empty category, e.g. /category/view/2 where category 2 is empty, the resultant error tells you there are no posts in the category. That's it, even when you're logged in. The option to delete the category should show up on this page as well.

When deleting the last post in a category, it would probably make sense to offer to go ahead and delete the category as well, too.

Somehow I suspect this isn't the best way to do things.

I need to declare some actual relationships, but before I do that, this database schema really needs some work. For example, I think "group" is a reserved word in SQL, but I called a column group in the users table. Whoops.

Since I just put a checkbox on the edit category and edit user page, I'm wondering if I even need a delete post page. I could just as easily implement it on the edit post page. Or for that matter with JS. Hm. Maybe I need to play with JS.

The point is, I'm leaving it how it is for now until I make up my mind. I'm just writing this so I don't forget about it in the meantime.