Simple Blog Feed

[cpgillem]

The front page could use a simple feed of news updates and announcements. I think we could just have it pull from a directory of markdown files like Jekyll. The only features it needs are date sorting and the ability to pin posts to the top if they're important announcements.

I'll get on this eventually if nobody else gets to it before me.

[dyladan]

why would we back it with files instead of a database?

On Sun, Apr 19, 2015, 12:53 PM Cade Gillem notifications@github.com wrote:

The front page could use a simple feed of news updates and announcements. I think we could just have it pull from a directory of markdown files like Jekyll. The only features it needs are date sorting and the ability to pin posts to the top if they're important announcements.

I'll get on this eventually if nobody else gets to it before me.

— Reply to this email directly or view it on GitHub https://github.com/ccowmu/whatistheplan.com/issues/33.

[cpgillem]

Do you want to put all data and content for posts in the database? That should work for us, even if we can't put large posts in it. There's also the option of storing the filename for posts in the database along with their metadata.

[rhinoceraptor]

It seems like defining a simple blog post schema and then getting posts from the database would be easier than trying to hack in pandoc or perl markdown, especially if we want to maintain the same look across the site.

We could have each page display n posts, and get those from the database. Then put them in an array, shuttle that into an django HTML template and then define the markup to display each post. And then the next page will be the next n posts.

Maybe the first version of this feature should be text-only, then we can think about supporting images?

[cpgillem]

I think, as far as design, if we want to limit it to text, and if there are any images to show, they'll be shown at the top of the post, either horizontally or vertically. We should also support links. Other than that we don't need to worry about headings, paragraphs, bullets, or anything else.

I think this would work with your idea.

[klobucar]

Sine you already use django I'd recommend in this case storing them in the DB with a django model. I'd be willing to help out here as I used Django extensively for 2+ years in a production environment. :)

[klobucar]

If you store the blog post as a blob in the DB and style it with common CSS tags.

You could also have a short heading field for a text only representation fairly easily.

Here is also a popular blog add-on for Django. http://docs.django-blog-zinnia.com/en/develop/index.html

[cpgillem]

@klobucar Dang. Yeah, you're exactly what we need. There's always been some doubt about whether Django is that necessary for this project, but we are building in a couple functions that use databases and might be more tedious and error-prone with a static site.

[rhinoceraptor]

And then the view for the blog posts would handle the post serialization and pagination?

We should probably split up our views since we don't want every view in one views.py file.

[cpgillem]

I've noticed that we aren't separating any functionality into apps, but lumping them all into the site. I feel like we can use an external blog system and build separate apps for user profiles, brackets, and events.

[klobucar]

Feel free to email me or hit me up on IRC if anyone would like some advice on how to structure the Django app and test it.

[cpgillem]

@klobucar What is your IRC name, by the way? I don't know if I've even talked to you before. I'm cpg.

[klobucar]

@cpgillem I'm Crowbar

[klobucar]

@rhinoceraptor A little off topic perhaps, but Django does require more work than say a static site such as Jekyll. However if it is documented, kept simple, and has tests it should work nicely and provide a little experience and experimentation for those who want to learn.

[cpgillem]

@klobucar Exactly. This isn't primarily about finding the BEST solution and implement it the FASTEST. Computer Club's educational. We have a few months to learn a new framework and get it to suit our needs. If it turns out it sucks to maintain after that, I don't have a problem with building it again in something better. Then we'll know two frameworks.