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.
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
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
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