views:

209

answers:

3

The Django apps come with their own features and design. If your requirements don't match 100% with the features of the contib app, you end up customizing and tweaking the app. I feel this involves more effort than just building your own app to fit your requirements.

What do you think?

+7  A: 

It all depends. We had a need for something that was 98% similar to contrib.flatpages. We could have monkeypatched it, but we decided that the code was so straightforward that we would just copy and fork it. It worked out fine.

Doing this with contrib.auth, on the other hand, might be a bad move given its interaction with contrib.admin & contrib.session.

Peter Rowell
Actually, contrib.session doesn't use contrib.auth, it's the other way around so you could still use that. Also, it's not terribly difficult to develop your own user model for auth purposes that has a foreign key back to contrib.auth User if you want certain users to have access to admin tool.
Joe Holloway
You are correct. I had a vague memory of a session-related problem, but it was auth storing authentication module info in the session, and then we moved the file the code was in and it broke. So, never mind on the session comment.
Peter Rowell
+4  A: 

Most of the apps in django.contrib are written very well and are highly extensible.

Don't like quite how comments works? Subclass the models and forms within it, adding your own functionality and you have a working comment system that fits your sites schema, with little effort.

I think the best part when you extend the contrib apps is you're not really doing anything hacky, you're just writing (mostly) regular Python code to add the functionality.

Bartek
+6  A: 

I'd also check out third-party re-usable apps before building my own. Many are listed on Django Plug(g)ables, and most are hosted on Google Code, GitHub or BitBucket.

akaihola