--
Software Architect
http://daitangio.homeip.net
http://www.objectsroot.com
Paul Bissex - http://e-scribe.com/news/171 - has done a *very* small
Wiki implementation.
Cheers,
Tone
ciao ciao
Patrick
Do not count this post as self promotion but you can also check my
personal site :) Here is how it looks like:
http://step-inside.org
And here you can browse sources:
http://step-inside.org/projects/stepinside/browser/trunk
Though it is not ported to the latest version (post magic-removal) of Django.
Regards,
Konstantin
The code for the djangoproject.com blog is open source:
http://code.djangoproject.com/browser/djangoproject.com
Looks like it hasn't been ported to magic removal either. :-(
Bryan
I'm coming from a similar camp. I've had a blog running on Zope with
COREBlog for about a year and a half. I want to be able to move all of
my content over without losing anything.
The good news is that I've gotten most of the way. The bad news is that
I still haven't switched over. I currently have a weblog implementation
modelled after the COREBlog metadata. I have a migration tool that I
run via the Django shell. It converts all of my entries and comments.
I'm hung up on a few things.
1. Photo handling
I have quite a few dozen entries with photos (out of 100+) and I want
to add lots more. I currently crop the images down to an acceptable
size and include them inline to the story. I would like to have some
more advanced way of handling images so visitors can get full size
images easily, so I can put up film-strips and slide shows.
2. Comments
I like the ideas behind the comments API the ships with Django, but
the metadata collected doesn't match up with what COREBlog was using.
I started creating a new comments API that is a blend of Django and
COREBlog, but I keep getting stuck and procrastinating. What has me
hung up at the moment is that I want to store the IP address of the
commentor. I don't want it edittable, but I want it displayed in the
admin interface.
I started hacking on this pre-magic removal and I have since removed
most of the magic from my code. I always admired Zope, but Django seems
a lot easier to get a long with.
Nate
Likewise, I needed a photo gallery app, so last night I started
porting the stockphoto application
(http://www.carcosa.net/jason/software/django/stockphoto/) to
post-MagicRemoval. So far, I think I've gotten the model updated. I
still need to work on the views and templates. My fork of stockphoto
0.1 is at:
https://svn.wamber.net/projects/wamber/browser/stockphoto/branches/v0.1-post-MR
I hope to have the port done in the next few days (I'll post about it
here when I've finished).
Hope this helps
-- William
P.S. If you replace the 'project/wamber/browser' in the URLs listed
above with 'svn', you have the svn repository from which the code can
be directly subversioned off... e.g.
svn co https://svn.wamber.net/svn/stockphoto/branches/v0.1-post-MR
Thank you all for providing your code for us to take a look at. I've
finally gotten Django working on my Powerbook and CentOS box and am in
the process of writing a portfolio/blog app to get more acquainted
with how the framework works. Being able to see how others approach
things is a *huge* help... especially when I am trying to understand
how everything interacts with eachother within the framework.
As of today, it has indeed been ported to magic-removal.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
And there was much rejoicing!
Just an aside in response to the request that the blog writers all get
together and not waste resources, take a look at the code they are
writing. Actually, take a look at the code they are not writing. A
basic django blog app can be done using generic views and very little
code (see the djangoproject.com code, or read [1]). The unified
Django blogging app is little more than a collection of generic views.
The reason you see 3 or 4 (or more) different blogging apps is
because people like to customize a little. It's the same thing you
see with wordpress and all its plugins. Sure, a good number of people
just use the basic default wordpress, but after a while everyone
starts to customize at least a little. Doing it with Django just lets
you customize with clean, organized python code, instead of, well,
PHP.
Bryan
1. http://www2.jeffcroft.com/2006/may/02/django-non-programmers/
I'm also trying to find ways we can reduce our overhead and the time
it takes to get our projects out the door (that we can control
internally). RoR is a nice replacement for PHP but Django is a much
better fit for the majority of the sites we delpoy for our clients.
You use the right tool for the job and I think we've found a great
tool for our tool belt!
>
> Just an aside in response to the request that the blog writers all get
> together and not waste resources, take a look at the code they are
> writing. Actually, take a look at the code they are not writing. A
> basic django blog app can be done using generic views and very little
> code (see the djangoproject.com code, or read [1]). The unified
> Django blogging app is little more than a collection of generic views.
> The reason you see 3 or 4 (or more) different blogging apps is
> because people like to customize a little. It's the same thing you
> see with wordpress and all its plugins. Sure, a good number of people
> just use the basic default wordpress, but after a while everyone
> starts to customize at least a little. Doing it with Django just lets
> you customize with clean, organized python code, instead of, well,
> PHP.
Hi Bryan.
while I do agree that django is easy to use, I'm trying to take the
user point of view.
What we have got (IMHO) is 3-4 blogs which don't have many features
when compared
to wordpress or typo, and as such a user (or future developer)
wouldn't be interesting in installing them
and choose something else.
if you combined I can imagine you would integrate features like
- askimet spam tracking
- auto tagging from tagthe.net
- pingbacks
- themeing
- multi-user support
- captcha of some sort
and so on.
so I see a blogging app more as a opportunity to lure more developers
into the django community, than a learning exercise for a developer
(which of course is also a great reason to build one in itself)
regards
Ian
>
> Bryan
>
> 1. http://www2.jeffcroft.com/2006/may/02/django-non-programmers/
>
> >
This is why we need some sort of repository of django apps. A
Djangoforge if you will. Wasn't that one of the SOC projects? is it
being done? Are there plans? Something like that would be a great
magnet and would help people co-ordinate and remove redundancy.
I've been following the discussion with interest. I've seen that many
of you have concentrated on the actual code. But something I would
find also helpful/interesting is a "standard" model of blog. Or, to
push the idea further, a djangoforge of models.
Often, the model is one of the parts that must be right from the
beginning. And a common model would be ideal for interoperability
between applications, in this case blog applications, allowing easy
migrations.
This would allow me, for example, to start programming my own blog but
change to a more evolved one (the common development branch you've
been talking about in this thread) without major problems.
They already do it with data and pre-defined XML formats, why not with
database models as well?
Just a though,
G
> I've been following the discussion with interest. I've seen that many
> of you have concentrated on the actual code. But something I would
> find also helpful/interesting is a "standard" model of blog. Or, to
> push the idea further, a djangoforge of models.
>
> Often, the model is one of the parts that must be right from the
> beginning. And a common model would be ideal for interoperability
> between applications, in this case blog applications, allowing easy
> migrations.
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.
Cheers
Jarek Zgoda
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.