Where is Django’s blog application?
In terms of people looking for sample code or example applications to use/learn from, “where can I find a good Django-powered blogging application” is probably at the top of the frequently-asked questions list both on django-users and in the IRC; part of this is simply that, right now, there is no “definitive” Django blogging application; there are a bunch of them available if you go looking, but you’re not likely to get anyone to recommend one of them as “the” Django blogging app (unless the person doing the recommending happens to be the author of one of them).
In a larger sense, though, I think there’s a big gap between what people want/expect/look for from a Django-based blog and what feels “natural” to do in Django, and that gap is probably the reason why there isn’t — and may never be — a definitive Django blogging application. As it turns out, this also leads neatly into some important ideas in designing Django applications and some speculation on an important shift in methodology, so let’s take a deeper look.
How I built this site
When I sat down to rewrite my Django-powered blogging application, I had a specific feature list in mind and started out implementing things on it one by one, but along the way an interesting thing happened: instead of ending up with a single all-in-one application to handle everything I wanted, I kept spinning off separate applications to handle specific bits of functionality. Most of the apps I’ve released over the past six months — things like comment_utils, the contact-form app, etc. — started out as features which were going to be integrated into my blog app, but became applications in their own right.
The reason for that is pretty simple: Django encourages a development model based around tightly-focused “pluggable” applications. I needed a contact form, for example, but that’s something I’m going to need for lots of different projects, so I spent a couple of nights making it a bit more generic and reusable, then released it as its own application. Ditto my template utilities and comment-moderation code. When I wrote the app that powers djangosnippets early in the year, I did the same thing: user registration was something I knew I’d need all over the place, so tying it tightly to the snippets app, when I could just as easily break it out into a reusable application, wouldn’t have made much sense.
So when I did finally finish my blogging application, it was pretty lightweight; the code is online (though unsupported and undocumented right now, aside from docstrings embedded in the code itself), but you’ll find that it’s really just three models and some wrappers around generic views. Everything else was supplied by other applications; django.contrib.admin provides the admin interface, django.contrib.auth does what little authentication I need, django.contrib.comments provides the comments system, and a combination of other contrib apps and my own and other folks’ third-party applications round out the full functionality of this site.
In general, that’s what I personally want from a Django blogging solution: something that can be plugged into any site I happen to be working on, and which is happy to “do one thing and do it well”, trusting that other applications will take care of functionality outside the direct scope of writing a blog.
But that’s not the only way to do “blogging”
Meanwhile, most popular blogging software — Wordpress, Movable Type, Textpattern, etc. — is oriented around almost the opposite philosophy: the blog application is a monolithic all-in-one system which provides everything: blogging, user auth, templating, admin interface, plugin API, the whole nine yards.
There’s nothing wrong with that, of course, and the popularity of software like Wordpress is a testament to how effective this methodology can be, which is probably why so many discussions of Django-based blogging software end up involving the phrase “Wordpress clone” at some point. Having a single piece of software to install is an extremely powerful technique for improving adoption.
But it’s not something that really seems like it’d fit well with Django: you could write a monolithic Wordpress clone using Django if you wanted to, but you’d be reinventing an awful lot of wheels and tightly coupling them all to each other, which seems like it goes against general best practices for developing Django applications. Or, perhaps, focuses on a different use case than Django typically does: Django came out of an environment where the ability to put a site together by combining a default set of reusable “stock” applications and a few customized site-specific apps was essential, and that sense of being focused less on monolithic “all-in-one” applications and more on sort of “reusable building blocks” remains in Django (and is generally a good thing, if you’re a web developer looking to build things on a deadline).
Which brings us to the gap
I think this points to the primary reason why there’s not a “definitive” Django blogging application: writing one app which would handle all the things expected from a traditional blogging package like Wordpress simply doesn’t feel natural in Django. Again, that’s not to say it couldn’t be done, just that there’d be an inevitable temptation to start spinning functionality off to separate applications. I’ve been there, I’ve done that and I know that sooner or later you just get fed up feeling like you’re going against the grain.
And from the perspective of a developer using Django, a Wordpress-style self-contained “all-in-one” solution probably won’t be as attractive as something which can be plugged into an existing site and take advantage of other standard and/or popular Django applications. An app that requires its own administrative interface and user auth system separate from django.contrib.admin and django.contrib.auth, for example, would always be a second-class citizen in the larger ecosystem of Django applications.
How to resolve this?
At work, we develop, use and sell an online publishing system, geared towards news organizations. It’s called Ellington, and it’s the system from which Django was “extracted”, in much the same way that Basecamp is the system from which Rails was extracted. Ellington is not a single application, though; it’s actually a collection of Django applications, each of which focuses on a narrow aspect of doing online news, but all of which complement (and in some cases depend upon) each other. That’s been a great model for us, because it opens up the ability to build sites by mixing and matching a subset of the standard Ellington apps, or to sell “editions” of Ellington focused at different types of sites.
Ultimately, I think the only way to resolve the tension between the desire for “all-in-one” packages and pluggable “building-block” apps is going to be this sort of approach: rather than a single definitive “Django blog” application, for example, I think it’s much more likely we’ll see a collection of applications which, taken together, provide all the key functionality (while allowing a certain amount of mixing and matching in order to customize the finished product). I don’t have any idea what the packaging for such a thing would look like, since I’m almost certain that all of the apps won’t be developed by the same person or group of people, but it’s something I’ve been thinking about a lot lately, and I’d love to hear ideas :)
Feed of latest entries
November 29, 2007
#
Also, before things get going here, let me point out that I’m well aware that someone who had an axe to grind about framework design would probably say that what I’ve explained above ought to be true of frameworks themselves, and would probably try to turn this into a “Django is bad because it’s not a pluggable collection of components” argument. That sort of person can go grind that axe somewhere else; if I see comments to that effect, I’ll delete them, because I’ve basically given up on having sensible online discussions about framework design at this point.
November 29, 2007
#
Good piece, James. This realy needed to be publicly explained.
I have an idea what such a package might look like, and if me (and a couple people working with me) get our ducks in a row, I might just show everyone Pretty Quick Like™.
Hint, hint. ;)
November 30, 2007
#
Glad to see a post like this. The monolithic nature of Wordpress has always been a major PITA when it comes to customization. When someone wants something it’s a kick in the code to make it happen, and then God help you if you need to update the monolith to fix a security problem in an area you had to customize to get something else to work.
Also cloning Wordpress might not be that great of an idea, I’ve seen a lot of end users have a fair bit of trouble using Wordpress because it was too… I don’t know I guess they just don’t understand the paradigms of blogging let alone the scope of Wordpress.
Besides if Wordpress fills the “blogging roll” so well that everyone wants to copy it, why bother? Get on with making things that aren’t blogs. How many identical personal journals completly devoid of real interaction or creativity does the world need?
Can we come up with a better “killer app” than Wordpress? Django was born in the commercial world of publishing and it’s been my experiance that most of the users seem to have some kind of commercial slant to their dreams for Django, so since a strict Wordpress clone / blog app wouldn’t be all that useful for that dream why not make a “killer app” that is a collection of killer modules configured in some stereotypical way… I’d recommend a web store with blog capabilities or something like that but even that might be thinking too small.
November 30, 2007
#
Really, creating a blog in django is just a good exercise for getting aquainted with django. I had a moveable type blog for years and in the end just used the django-admin’s inspectdb tool to convert it django. Add a couple views and new templates and viola, it’s a blog.
Hacking on the MT codebase was such a drag. I’ve done the same thing to textpattern projects too. I disavow any knowledge of php now. P H What?
November 30, 2007
#
Noah: In terms of web store the Satchmo project (satchmoproject.com) seems to be coming along pretty well. From what I’ve seen of the websites that are already using it so often if you weren’t told it was Satchmo you wouldn’t have any idea what it was running on the backend for its store functionality. You can’t say that about any other open source store software that I’ve seen and Satchmo is “just 0.6” in terms of planned functionality. Sites that use Satchmo generally have nice designer looks and amazing clean URLs (/product/kona-coffee/ rather than /store/products.cfm?id=190834070) and they integrate well with whatever else that you feel like building into your Django site. There’s nothing stopping you from building a Blog + Satchmo store on the same website, and everything encouraging you to customize to your heart’s content. Satchmo itself is built in pieces and uses the existing Django contrib Auth and Admin, as every good Django application should, and it goes on to encourage using James’ comment-utils and django-registration for their nice wrappers around common needs… Maybe not a “killer app”, but certainly some shining beacon of the flexible Django approach versus the monolithic “CMS approach” of other currently more popular languages.
November 30, 2007
#
I definitely agree that using auth, registration, comment systems from Django itself makes sense, but I somewhat disagree that a blog system using Django would be trivial.
For example, there are many different offline blogging tools out there, and to connect to a blog these tools need access to and knowledge of some type of publishing API. MetaWeblog API is the one that seems to be catching on, but my point is that this API would need to be part of the blog application. It couldn’t reasonably be decoupled.
Another feature of the major blogs is that they will automatically ping different services upon publishing (Technorati and Google Blog Search come to mind). Some sort of method of specifying the services which need to be pinged should be included in any Django-based blog app. This again couldn’t be reasonably decoupled.
The final thing that I can think of that would not be able to be reasonably decoupled is a trackback/pingback implementation, which is a fairly common feature in modern blogging software.
With all of these ingredients, we no longer have a few models and some wrapper functions, we’ve got a nontrivial app with several customization points, and some real value when paired up against the big hitters like Wordpress.
Note: Your Coltrane app is a simple yet elegant solution to its specific usecase. I hope you don’t take my comments as belittling to that in any way, as that’s not my intent.
November 30, 2007
#
I also thought about this and got to a similar (but slightly different) explanation. Django is actually focused on building this type of web sites. It is just too easy to build a blog. Of course I can see the benefits of having “the Django blog” which can be easily used by non-programmers, but it seems that nobody wants to go through the pain of maintaining it for such a little added value.
November 30, 2007
#
@Eric: The things you mention (publishing API, pings, etc.) are features that are blogging-specific. Therefore, they should go in a Django blogging app, and probably should not be decoupled. The design philosophy for Django apps is generally to abstract pieces that can be reused in many contexts into their own, more generic apps. Those pieces which are specific to one context become a separate application.
So, for example: James could add pings and a publishing API to Coltrane, a blogging app, because these features are just for blogging. But he probably wouldn’t add comment functionality to Coltrane, because comments aren’t just for blogging. Likewise, he probably wouldn’t add the ability to upload photos to Coltrane, because photo uploading is a feature that could be used by many apps, not just blogging.
James isn’t at all saying there doesn’t need to be blogging app for Django — he’s just saying that blogging app would never be as monolithic as Wordpress or its ilk, because Django’s pluggable apps philosophy suggests that pieces with aren’t just for blogging should be their own, separate apps.
November 30, 2007
#
@Jeff: I definitely agree with everything you said there :) I was just trying to point out that even a very blog-specific app (like you said, no image galleries, no comments, etc.) can be a significant app in and of itself. And coupled with other pluggable apps, it could be just as good (probably better!) than the monolithic blog engines out there.
November 30, 2007
#
It’s nice and all that you’ve released this blog application, but it’s not very usable with no documentation, is it? How exactly do I find out what variables are getting passed to the view? So I can iterate over to print out the entries. How about making 3 basic templates that show basic usage of the application?
Regards, Max.
November 30, 2007
#
Yeah, and Django encourages doing separate applications for separate things. :) I wrote my own blog, using few existing apps - and extracted pingback application from it. :)
November 30, 2007
#
I agree with Glen, whenever people ask in the IRC channel about what django blog app they should use, I tend to suggest they write their own, as it’s such a good exercise for any django user (not just beginners).
November 30, 2007
#
@Jeff: At the same time though, “blog” is somewhat of a euphemism for “a collection of articles arranged in a specific way”, which covers anything from a newspaper to a collection of recipies. A publishing API could be just as useful for a news site, or a review site, or anything else that could use input from an external source. It’d be nice if said API was decoupled from any blog app into a more generic API class that could be customized for different models and views.
As for a blog application, I agree with some sentiments above, to an extent. In many ways, if a person is looking at Django in the first place, then I think it’s a safe assumption that said person wants to be able to customize and roll his own. As such, whereas components may help, I wonder how long they will be used.
In my personal case, I used FreeComments at first, but eventually replaced it with my own comments system in Django after bumping up against limitations in the contrib.
In a way, providing basic blog components is more like scaffolding in Rails — something to use to get things working whilst you work on something more custom that fits the role better.
November 30, 2007
#
Jeff, wouldn’t it be possible to handle that by publishing each application separately (as an egg) and specifying dependencies from the main blogging apps to all the function applications that were spinned from it?
That way the user can just download the blog project (it may be useful to have one), easy_install the blogging application, and all the lower level applications (commenting & stuff) will be automatically downloaded, installed, put on the pythonpath and be ready for the project and the blogging app to use.
November 30, 2007
#
It’s this kind of development philosophy that Drupal follows (might be worth a look at for some ideas). I may be a bit biased when talking about Drupal (seeing as I use it for a few sites) however I think it’s doing the right thing.
They use modules to provide functionality, rather than release a specific, focused application. One could arguably call Drupal a framework. At its core there is the basic functionality, which basically sets up a few static pages and a simple bloggish profile to start off with, along w/ basic commenting. By using some very powerful modules one can turn the site into almost anything.
Worth a look IMO, at least for the ideas (be warned you will have to put up w/ PHP :().
November 30, 2007
#
IMHO, it is too bad that parts of ellingtoncms are not open-source. The screen-captures are nice, but I’d love to see how it actually works and how the frameworks interact. My goal is to build a simple, easy to maintain blog + photo gallery. I’d like gallery ‘albums’ to be associated with a blog post. As someone who writes C/C++/fortran/perl/php, I’ve found learning python+django to be a PIA due to the lack of real-world examples.
November 30, 2007
#
Python is object oriented, so put your design pattern thinking caps on now:
An entire blog is composed of blog entries. A blog category is composed of blog entries. Blog search results are composed of blog entries.
If ever a type of web app was screaming out to be constructed using the composite pattern, it would be a blog.
Have fun
November 30, 2007
#
I always wondered if the Ellington team would ever consider open sourcing their project - as it would definitely increase the public “awareness” of django powered apps, since I assume it would be a large success and we’d see more sites powered by django, ellington, etc. Right now it’s easy to choose the alternatives, and usually php, cms/blog apps because well…they’re free, or cheaper, and they have a large open community behind them.
But yes, obviously everything can’t be for free (or can it?) so why not then offer a more advanced feature set or “commercial” app features that offer greater functionality that aren’t available in the free, open source version?
So essentially it would be an open source project that has a commercial aspect to it - similiar to how Wordpress, MoveableType, etc.
I think it would be a great strategic move for not only the Django community, but also for the Ellington team. Maybe even a little marketplace would unfold where people are offering free open source apps for Ellington, or commercial ones as well.
It’s just something I find interesting since ellington is probably the most visual django “product” out there.
And then there’s always ways to monetize the hosting, etc.
But I digress…
Also, what about the Flother blog app?
It”s a great looking blog, here’s an example: http://www.flother.com/blog/
And it’s available on google code: http://code.google.com/p/flother/
Looks like it could use some work - categories, tagging, meta blog api, etc…but like you said, it’s a start.
November 30, 2007
#
I’m moving the company sites off wordpress precisely because the monolithic format didn’t got in the way of people trying to get some content up, rather than expediting the process. In our setting, people found it to be baffling, irritating, and such a PITA to use they just avoided it altogether. For a lone blogger it may be great, but in our environment the difficulty one faces in truly customizing it and making it suit OUR needs sounded the death knell.
And so far, everyone seems really happy with the Django version, which is ridiculously easy to build to their needs, even for a hack programmer like me, working from a lot of off the shelf components.
November 30, 2007
#
I started looking at Django because I wanted a custom blog app and trying to really customize wordpress and textile is a major pain. At first, I was really disappointed that there was not already a good Django blog application out there but now I am very happy that I had to write my own. It forced me to really learn Django and not just enough to figure out how to install an application. With that said, it was crucial for me to have some sample blog code to learn from while I was developing. So long story short, I think that having some sample applications out there but not having full blown blogging platform is a good thing. It forces you to learn Django but also gives you some help along the way. I would think that most people that are switching to Django are people like me, people who are willing to get their hands dirty and do a little programming. For those who do not want to do this, wordpress and textile should meet their needs.
Also, someone mentioned having blog pinging and I thought I would mention that this is what I came up with for that.
November 30, 2007
#
First question that comes to my mind as soon as we start talking about apps built upon Django: How does one nicely deploy such an animal?
Having written a handful of Django sites, and admittedly not being hugely aware of the larger Python software ecosystem, I can’t even begin to imagine how one would structure code and content so that you could, say, distribute a tarball and give the user a nice, mostly-web-driven installation process, on the order of what Wordpress does. Any good writing or Py tools out there that might help make it clear(er) how to go about this?
It’s one thing to be able to pick up one of my apps (or a collection of apps) and move it to another host, tweaking up config files and apache conf until it comes to life — another thing altogether to give an unknown end-user on any one of a number of OS environments a straightforward and relatively pain-free installation experience.
November 30, 2007
#
I’ve been working on a blogging application(here for those interested) and one of the philosophies we are running on is that we use django’s builtin stuff and everything else is self contained(For example he have added tracebacks). I think one of the reasons there are these 2 opposing philosophies is that the plug and play model works very well for other developers, while the monolithic style is great for distributing to non-coders.
November 30, 2007
#
I do not agree that there will never be a full-fledged Django blog app. In my opinion, the problem is that writing a complete, customizable, and performant blogging app is a lot harder than it looks.
In fact, I have been developing a more or less full-featured Django blog app on and off for the past few months. Right now it has:
multiple-format text fields which use a set of conversion functions that accept a specific format as input (eg textile, etc.) and output HTML; thus each post can be written in a different format (or users can select their preferred format to write posts)
per-post datetime fields with UTC, local time, and timezone (eg you can write posts using different timezones and they will be fetched and sorted according to utc)
a spam filters chain with a few predefined filters using whitelists/blacklists/akismet etc.
content filter chains for both posts and comments
actions, eg lightweight plugins to attach behaviour to the events that raise signals
an XMLRPC interface compliant with the MT API
weblogs ping (it’s just one of the above mentioned actions)
incoming and outgoing trackbacks
multilevel categories based on SQL trees
theming
And a few other features. It’s really meant to be a multiuser, multiblog app someday (and so certain features make more sense in that context), but right now it’s a straightforward, pluggable Django app.
Thous it’s still missing a few important pieces (like a proper admin console, and a pervasive caching mechanism), it’s been in production for a couple of months on my blog (qix.it) and a couple of my friends’ blogs, and it’s behaving pretty well. If anybody wants to help developing, or check it out, the repo is at http://svn.luamboblog.org/ and a preliminary trac install at http://trac.luamboblog.org. You can contact me at ludo_at_qix_dot_it. Sorry for taking so much space, but I think my comment is relevant to this post’s topic. Feel free to delete it if you think otherwise, of course. :)
November 30, 2007
#
I’d echo Haze’s sentiment that Drupal’s module/hook architecture is a good place to look for ideas.
November 30, 2007
#
I suspect we’re going to have a wave of Django blog/”CMF” applications hitting within the next year. I’m going to guess 2 or 3 backed by small shops and one or two community driven ones. There are enough people and companies using Django for projects outside of the scope (or budget) of Ellington that it’s bound to happen. I’m just hoping it happens a little differently than it did with Rails (which I think fizzled in this department a bit).
Honestly I was hoping it would hold off a little bit longer because I have some small plans in the works, but at the same time I’m excited to see what’s going to show up.
@Jeff Croft: I had a private hunch that you would be the source of one of these systems, perhaps with Blue Flavor… That would be nice to see.
November 30, 2007
#
Max Battcher: I know about the store, it’s not “killer” though, it’s not MORE capable and EASIER to use than anything else.
November 30, 2007
#
My thinking on this runs in line with Masklinn’s.
A full django blogging app that tried to please everyone would end up pleasing few. But a central location (more focused than django snippets) for applications that solve common blogging problems. Start with a basic Entry-related blog app, then have pluggable social bookmarking, spam prevention, pinging, etc available from the same location.
Making my blog has been how I’ve learned a lot about Django. I encourage everyone learning to do the same. But sometimes I’ll be solving these problems and think, “surely someone else has solved this, too. this might make for a good blogging application piece.”
November 30, 2007
#
I’d love to see applications become more hierarchical, and for there to be a distinction between an application, which has some user-facing components, and a library which is used by applications.
They way a blog could be an application that uses several libraries, some of which are public, being available to all other applications, and some might be private, available only to the blog.
Libraries would basically what applications are now, but applications would have their own settings.py file that pre-wired their functionality together. Installing an app would be as easy as adding it to INSTALLED_APPS and including it’s URLs.
This can mostly be done now with a few additions to settings.py.
November 30, 2007
#
In many cases, the documentation and step-by-step examples are geared for the beginner and not the intermediate. Cookbooks & example apps are what intermediates need.
December 2, 2007
#
I posted the code to my weblog application here…
http://joysoup.net/weblog/2007/12/djangosoup/
It’s my first Django application. A newbie might be able to learn something from the code. Joysoup is a first attempt and I’d appreciate any suggestions.
December 3, 2007
#
For completeness’ sale, there’s also Banjo, written by Bruce Kroeze, one of the Satchmo developers:
http://coderseye.com/2007/banjo-blog-nearing-01-release.html
December 3, 2007
#
The issue I was concerned about when deciding what to reuse and what to rewrite for a blog application was the interface. I wrote a blog application for two sites that were primarily print publications and staffed largely by people who’d done little blogging and had next to no tech knowledge. Throwing that type of person headlong into the standard Django admin app felt scary; if there’s one good thing you can say about Wordpress (and honestly there are many good things I could say about it), it’s that it’s fairly good at presenting a streamlined interface to the noob blogger, while the Django admin takes the stance of “show the user everything and let them sort it out.” That’s good in some circumstances but it felt like too much to show our bloggers (“what’s a slug? can I preview a post before editing it? how do I save a draft instead of posting? how do I bold stuff or put a photo in?”).
In the end I wrote a UI that could handle showing different model-specific fields depending on a user’s credentials (blog editor vs. blogger), do simple row-level permission stuff (view own drafts vs. view all drafts, or edit own posts vs. edit all posts), and wrap a nice UI around things like adding HTML or seeing a live preview of your post. Considering that the admin interface was designed for a fairly specific use-case, it seems to me that what would really be useful for a lot of applications is not necessarily changes in their core functionality, but in the interface they present to editors/writers. The major disadvantage of this approach is the tight coupling, unfortunately, but I don’t see any good ways around this (maybe other people do?).
December 4, 2007
#
I agree with Masklinn. It would be nice to have a Ubuntu-style repository for modules and libraries. Someone can download a blog or an app, and type “python manage.py install-dependencies” for it to search the import statements and download and install anything it recognises. This is quite complex though.
And Justin, what about apache2 style “apps-available” and “apps-enabled” (the latter symlinks to former), where the dossiers in the latter are scanned and automatically added to INSTALLED_APPS?
Finally, a central repository for name-spaced models would be a help to kickstarting apps. Eg repository.basic.article is a basic class for an article model, repository.banjo.article extends repository.basic.article. I understand this will breakdown quickly as apps become dependent on the extended model, but it will create a library of ready-to-go models without each person reinventing. All it would take is an extra function in django remote_import(‘http://djanjo/repo/models/basic.article’) which does a svn checkout if it doesn’t exist then caches it locally. This way you could download half a dozen different basic blog apps, drop them into the apps-enabled directory, and straight away they will all work and on the same database as they share the same basic models.
Just ideas,
Phillip.
December 5, 2007
#
Hi I’m a total newbie to django I’m fresh from the tutorial trying to learn by looking at some production code. Coltrane looks cool since its so small but useful I’m using the sVN version of django and SVN version of coltrane I noticed that there’s a missing module ??? comment_utils?? Regards Chris
December 5, 2007
#
Chris, as I said above in the main entry, my blog app is completely undocumented and completely unsupported at the moment. Right now, you shouldn’t try to use it unless you really know your way around Python and Django and don’t mind figuring some things out on your own.
December 6, 2007
#
We just released a free blogging app for Django. It includes trackbacks, ping and comments with moderation and honeypot spam prevention. See today’s post for details.
December 7, 2007
#
The idea of learning django by writing your own blog in it is a good one, but not everyone learns best that way. I much prefer diving into a fully-fledged project than pulling myself up by my own bootstraps. And as ludo points out, the basic functionality is easy, but blogging these days is more than just some posts in a database. Where’s the “preview” button on this comment form for example?
December 8, 2007
#
James - i appreciate the ‘no support’ aspect of your blog project - but how about a bit of a hint on settings.py and urls.py? I have the admin working, just trying to learn Django by muddling through your code and am running into some newbie issues.
thanks
Damon
December 8, 2007
#
@Eric, Jeff, David: How well does the recently-finalized Atom Publishing Protocol (AtomPub, RFC 5023) fit the API needs you see?
Also, one thing I’ve looked for in each blogging app I’ve considered is how well it supports both saving and loading the data via the ATOM format.
Another pretty fresh blog app I stumbled across recently is Djog http://dev.oebfare.com/projects/djog/
December 10, 2007
#
+1 Damon!
I ‘d also appreciate a hint on your main settings.py and urls.py :)
Thanks , Christos
December 10, 2007
#
Okay, I give up on coltrane. You might as well not have released this code, it’s utterly impossible to use for people who have not been using django for at least 6 months. There is no hint at all how comments work, there is no feed, it’s all like a big obscure piece of code. I’m looking at it, and I absolutely cannot figure it out. I assume that the comments is somehow related to the internal django comment app, but as the django book is missing that chapter, this is totally obscure.
Coltrane is not the django blog app. It’s a blog app for django programmers so advanced that they could write their own blog app in 2 hours. For the newbie django user, this particular release is nothing but an excercise in frustration. As I’m sure you can detect from the tone of my post.
December 16, 2007
#
Um, Max.. this might be a better place to start. It’s a great “blog howto” in and of itself, not to mention that it explains django’s db rather well. (:
I myself am glad that James posted the source code. docstrings are good enough for me. :D
Thanks!