Jarek Zgoda wrote: > I second that. Actual code may vary, but domain model (and its > representation as Django data model) would remain constant, as long as > software will be performing similar tasks.
Well, maybe. I think its really hard in any real application to have a one-size-fits-all data model. Even for something as seemingly simple as a blog, I think its a tough challenge. I, too, am one of the people who wrote their own blog in Django. I did it more as a project to force me to learn some of the less obvious things about Django then for the goal of having a blog (I ported from WordPress once I got the basics working). Even if such a "standard" project existed, I probably would have opted to start from scratch to just learn it - but my motivation might be the exception, not the norm. In any case, I think what you might end up with are a few model classes that have *many* optional fields to accomodate different uses. Just look at the comments model right now: it has 20 fields. My Post and Tag models have 8 and 3 fields, respectively. I think the right way to do it is to follow the Django approach with User: keep the generic model as stripped down as possible and let people extend it through subclassing (when that works, or via relationships for now). But I am +1 on the idea of a community blog project for things like photos, pingbacks, captcha, etc. The comments add-in is a good example of the building blocks I'd like to see, and use in my own project. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
