Presentation Abstract

Justin James and Brian Gershon of Web Collective will be talking about their recent experiences with Django, an exciting python-based web framework, and will show examples from both Django and Plone to give a sense of the strengths of each platform and when one might use one or the other. There are also some shared concepts between these two platforms. The presentation will be a high-level discussion, plus will also delve into some code -- so should be good for a technical and non-technical audience.

This is also an invitation to those that know Django really well to participate in the conversation, and also Django users that want to learn more about Plone.

Presentation Overview

• Introduction to Plone and Django
• Data Layer: How are data and content handled?
• Views: Connecting data, functionality and presentation
• Templating
• Time for Questions

Framework Goals

Goal of these frameworks are to:

• make it easier to build web applications by providing useful services and layers of abstraction
• leverage the power of Python — clean, object-oriented, fun to work with
• add your functionality as straight python classes without a lot of encapsulated framework. Leverage existing Python modules.
• Plone is mainly a CMS product — so best to compare Zope3 and Django frameworks

Why Plone (and Zope3)?

• Great for working with native content objects and supports both containment and relational data, but stronger at containment (via "folderish" content). Since Python objects are stored directly in the Zope Object Database, no mapping is required and it's very flexible for storing any sort of content.
• Roles and Permissions: Zope's object database has granular security baked-in. Permissions can be added without touching the Python classes (as part of configuration)
• URL Mapping: Concept of "context" and Views/methods.
• Heavier framework with benefits of lots of functionality (workflow, product architecture, component architecture, etc). A decent learning curve due to many new concepts to learn. Zope3 is a lighter framework than Zope2 and provides a sophisticated component architecture.

Why Django?

• Great for working with heavy relational data with its nice object-oriented layer on top of SQL; don't have to work directly with SQL for creating tables (Django Models) or running queries.
• Roles and Permissions at the code and template layer via Django's authentication/authorization system.
• URL Mapping: Flexible approach of mapping URLs (via Regular Expressions) to Views/methods
• Lighter framework and a faster learning curve due to great documentation and easy ways to apply existing knowledge. Can learn the core in a weekend.

Data Layer: How are data and content handled? (Plone)

Plone:

• Python objects are mapped to objects in the ZODB
• Object attributes can be easily defined and via Archetypes Schemas (Archetypes reference)

Data Layer: How are data and content handled? (Plone)

Plone:

• Objects are nicely tied in to Plone by subclassing existing Archetypes ( general references for developing with Archetypes )

Data Layer: Accessing data (Plone)

Plone:

• Once you have defined your Schema, a quick way to access the data is via Clouseau (an AJAX based Zope/Python prompt)

Data Layer: Accessing data (Plone)

Plone:

• You can also access an object's data and relationships in a script or view method

Data Layer: How are data and content handled? (Django)

Django:

• Python objects are mapped to tables, rows, and relationships via the Django Object-relational mapper (ORM)
• By subclassing from the django base Model object, you get concise definitions of SQL field types, and are saved from having to write any SQL. (reference for the Django model API)

Data Layer: Accessing data (Django)

Django:

• Once you have defined your model, you can easily access the data from a python shell
• You can add new data, and you can query the database. (Django database API)

Data Layer: Accessing data (Django)

Django:

• You can even traverse relationships with standard python dot syntax

Data Layer: Hierarchy and Relationships

Contained VS. Related:

• Plone works with the idea of folder-ish objects that can contain other objects
• The current best practice for defining what may be contained in a folder-ish object is via Generic Setup and simple XML files:

Data Layer: Hierarchy and Relationships

Contained VS. Related:

• While Plone works most of its magic via the idea of containment, it is quite capable of dealing with relationships.

Data Layer: Hierarchy and Relationships

Contained VS. Related:

• Django (being based on Relational Databases) uses standard SQL relationships (examples of database model relationships) and requires the developer to tweak anything that requires the idea of containment to fit with a relational data structure.

Views: Pulling together data, functionality and presentation

"Views" on both platforms are essentially Python classes that receive information from the browser, and return information back.

browser -> URL Mapping -> Python classes -> template -> browser

They differ in their approaches however.

What is a View in Plone?

...well, it's really a Zope3 View

• Python class
• Interface to describe the Python Class methods
• A template
• Configuration that connects the template, security options, etc to the View

Example Plone View: Show a list of ActionItems

(snippets from CollectiveGTD Plone product)

Calling a View in Plone

• Context is key - you navigate to an object via a URL and call Python methods directly. All objects in the site have an inherent URL.
• For example "stuff" is a folderish content-type that has a bunch of tasks in it, "actionitemlist_view" is a View (Python object), "getSortedActions" is a function in that class, and the remaining items are parameters passed to the function.

  http://localhost:8080/gtd/stuff/actionitemlist_view/getSortedActions?filter_by_tag=project:brownbag

Note: In Plone, you can setup views in two slightly different ways: You can call a template (and it can pull in the View functionality) or you can call a View directly and it will pull in the template. An example of the first way comes up shortly.

Plone View: Interface

Plone View: A Python class

Plone View: Template

Plone View: Configuration File

What is a View in Django?

• Python function
• A template
• A URL mapping to the View

Example Django View: Show a person's profile

(snippets from Skillbit.com product)

Django View: A Python function

Django View: Template

Django View: URL Mapping

Calling a View in Django

In Django, a common pattern is to map a url to a View, and pass parameters between slashes. It's easier to read than query string parameters.

    http://127.0.0.1:8000/profile/2/

Flip back to previous slide to walk through how this works.

Templating: The Presentation Layer (Plone)

• Plone presents data in templates using TAL and allows for the inclusion of pieces of templates within other templates, accessing scripts and view methods, working with ways to display data returned from methods, and embedding simple python statements (although this is encouraged to be used as little as possible). ( the TAL reference on zope.org)

Templating: The Presentation Layer (Plone)

• Plone templates treated like other objects in that they are in the ZODB and can be referenced via their id (which is defaults to just the filename without the .pt extension) and can be called directly in a URL.
• So, a url like: http://www.iclei-usa.org/main-page/home_page_view maps to the view template (home_page_view.pt) of object with the id of "main-page"

Templating: The Presentation Layer (Django)

• Django templates are written in a custom Django templating language (which is very pythonic) but which strictly enforce the separation of the presentation and data layers design philosophy of Django. (the Django template reference)
• Another key design philosophy of Django is interchangeability of components, so if you would like to you can use another templating engine (even TAL).

Templating: The Presentation Layer (Django)

• Django templates, like Plone templates, allow for the inclusion of pieces of templates into other templates, and also allow for the notion of templates extending other templates. This is similar to TAL slots and macros and allows for the use of a base or main templates that other templates can "extend" and override sections of the base template as needed.

Templating: The Presentation Layer (Django)

template extension:

Templating: The Presentation Layer (Django)

• The Django templating language gives you a lot of flexibility for traversing object relationships:

Wrapping Up

• Django and Plone both have a variety of other features we haven't covered, such as form tools, products, Admin interfaces (ZMI and Django Admin), etc.
• Questions?