This document discusses mixing the Django web framework with the Plone content management system (CMS) to create an e-commerce platform with advanced community features. It explores using the Satchmo e-commerce solution and Pinax community modules with Django, while retaining Plone as the CMS due to its content editing capabilities. The document outlines the integration challenges and solutions tried, such as common theming with Diazo, avoiding data duplication, and ensuring users are managed consistently across both systems. It advocates for a single buildout, with different configurations for development and deployment.

1. C³: Mixing Plone
and Django
for explosive results!

2. The requirements
● a modern e-commerce
platform
● with a good contents
story
● and advanced
community features

3. Plone alone... will get it done?
a good web CMS like Plone has no clue of:
● e-commerce needs
● advanced community features
no known Plone extension could convince
us and...
we didn't want to start any new Plone
project with this needs

4. The quest for a good solution
The Graal should:
● be python based
(we ♥ python!)
● not reinvent the wheel
● be open source
● have a community
behind
(we ♥ happy customers)

5. Attack of the ponies
We looked at Django:
● good and stable since
years
● with a strong and
passionate community
● had a proven
ecommerce solution
and a proven
community solution

6. The evil plan

7. Satchmo, the e-commerce
http://www.satchmoproject.com/
● feature rich
● flexible as we needed
● with a group of people really
using and improving it

8. Pinax, the community
http://pinaxproject.com/
● a suite of modules for community
purposes
● reuse what's already there
● good working example projects included

9. Why Plone then?
talking about web CMSs:
● python based
(we ♥ python!)
● not reinvent the wheel
● open source
● with a community behind
(we ♥ happy customers)
● "nothing compares to you"

10. It's a long way to the top
● integration, integration, integration
● choices, choices, choices
looking for sustainable and elegant
solutions

11. The Plone and Django dance
a coreographer's job
● Don't stomp on each
other's feet
● Don't do the same
things twice

12. The dance steps
● common theming via Diazo
● don't store the same data
twice
● let one see what the other
does

13. Ballet's preview

14. What about the users?
● CMS users are content
editors
● they do not mix with the
common people
● Users are common
across Django apps
● but not across Plone

15. I'm sure I had it somewhere
● Plone needs to read from
the database
● sqlalchemy? Duplication
of code

16. To import or not to import
django.db.models?
It is nobler in the code to suffer:
● The thousand errors of
circular dependencies
● Or to take arms against
settings.py, and by fixing that
end them
Hamlet did it wrong

17. Syncronizing the dancers
● Django handles the
transaction trasparently
via middleware
● Hook up the right
methods to Zope's
transaction machinery

18. I've got a fever, and the only cure is...
less code!
● Sharing the same logic
between Django and
Plone views
● Using django templates
in Plone
● That's the python, baby
(and you just have to
enjoy it)

19. Murphy's impedance
Some things we didn't quite
consider
● Internationalization and language
selection syncing
● Linking content between systems
● Paster vs nginx

20. Building the launch ramps
● Single buildout
● Paster+SQLite for
development
● Quick, pain-free setup
● PostgreSQL+nginx+uwsgi for
deployment
● More robust but also more
convoluted

21. Traps and dark pits
● The Content-Length
problem
● Aka “Hello nginx, I have
some bytes for you”
● Where's that cookie coming
from?
● An i18n tale of horrors

22. The duct-taped parts
● Static files and media files
● The slow agony of
settings.py

23. And in the end... they all lived on
github
● djc.recipe
● ~collective/collective.django

24. Towards the infinite, and beyond
● Integrating users
(PAS+repoze.who)
● Making
development
faster
● Managing themes
and files easily