In 2004 The Nature Conservancy adopted Plone as the platform for ConserveOnline.org, a community site for sharing conservation information. Since then, we have gained experience implementing several successful Plone intranet applications, made plenty of mistakes, and learned how to - and how not to - approach new Plone projects. This talk will compare our experiences developing two very different intranet Plone applications that manage conservation information. The first application has a complex data model with a relational database backend and makes minimal use of Archetypes. Its requirements - including data model and user interface - were rigidly specified based on a spreadsheet tool. The second application is Archetypes-based and was developed using UML modeling and ArchGenXML. It has a simple data model, uses the ZODB for storage, and its requirements were more loosely specified. From the lessons we learned on these projects, we have developed a set of application pattern definitions to guide us when choosing technologies and estimating costs. We think these pattern definitions can help managers, integrators, and people new to Plone understand when to use Plone, when not to use Plone, and how to structure their interactions with clients to ensure a successful Plone project.

1. Plone Application Development Patterns file:///Users/sek/tnc/naples/sallyk-slides/plone-patterns.html
Plone Application Development Patterns
Sally Kleinfeldt, The Nature Conservancy
October 2007 -- Naples
Overview
Background
First application: ConPro
Second application: EAST
Pattern Library
Questions
The Nature Conservancy
Environmental nonprofit protecting ecologically important lands and waters
Science-based approach
117 million acres protected
1 million members
Work in 50 states and 30 countries
3,000 employees
Background - Technology
Traditional IT shop
Supporting HR, Finance, database applications
Plus creating conservation applications
Adopted Zope in 2000
Nature.org, intranet, internal applications
ZMI development, RDB storage
Background - Technology
Adopted Plone in 2004
ConserveOnline.org, internal applications
Filesystem development, RDB or ZODB storage
Background - Applications
Spatial and non-spatial
Mix of data and content
Users, roles, permissions important
1 of 10 11/1/07 5:52 PM

2. Plone Application Development Patterns file:///Users/sek/tnc/naples/sallyk-slides/plone-patterns.html
Workflow sometimes
Increasing need for custom applications for conservation
Increasing need for cross-application integration
ConPro - What Is It
System to manage structured and unstructured information about our conservation projects
Information previously managed in complex Excel spreadsheets, and associated documents, often
in the field
Need for import, export, versioning, locking, security, search
ConPro - Requirements
50+ page functional requirements
Assumption of relational storage for ad hoc SQL queries
Spreadsheet dictated the data model
Users defined edit screen mockups based on the spreadsheet
Versioning, security, workflow requirements less clear
ConPro - Data Model
Customer-specified data model for RDB was very complex.
ConPro - Development
Plone chosen for compatibility with ConserveOnline
Unable to hire expert consultant to guide development
2 of 10 11/1/07 5:52 PM

3. Plone Application Development Patterns file:///Users/sek/tnc/naples/sallyk-slides/plone-patterns.html
Initial focus on spreadsheet import/export, SQL methods, edit forms
Design of classes, security, overall application left until the end
ConPro - Development
Archetypes stub objects for object security, the rest hand crafted SQL methods and page templates;
workflow not used
Customers changed their minds midstream about data model and edit forms
Rescued by Plone experts and much effort
ConPro - Results
Late and overbudget - 30 person months
~400 hand written SQL methods
50 hand written edit, display, report forms
Ad hoc SQL queries never implemented
Difficult to maintain and extend
Big success with users!
ConPro - Home Page
3 of 10 11/1/07 5:52 PM

4. Plone Application Development Patterns file:///Users/sek/tnc/naples/sallyk-slides/plone-patterns.html
ConPro - Project Info Page
ConPro - Project Info Page
Turn it on its side - here's all the information...
ConPro - Project Viability
4 of 10 11/1/07 5:52 PM

5. Plone Application Development Patterns file:///Users/sek/tnc/naples/sallyk-slides/plone-patterns.html
ConPro - Project Viability
Turn it on its side - here's all the information...
ConPro - Lessons
Avoid excessive requirements phase for new/unclear applications
Users should not dictate technology decisions
Relational storage increases cost, avoid if possible
Have guidance from experts on your first project, learn to do things The Plone Way
Start with classes, security, overall application functioning; page templates later
EAST - What Is It
5 of 10 11/1/07 5:52 PM

6. Plone Application Development Patterns file:///Users/sek/tnc/naples/sallyk-slides/plone-patterns.html
Ecoregional Assessment Status Tool
ERA: science-based analysis of an ecoregion to determine highest value areas for conservation
New system for management to track status of this work
<200 assessments, each with <20 attributes
EAST - Requirements
Well understood application
Initial version done in pure Zope prior to ConPro
Informal project driven by developer to re-implement The Plone Way
Customer flexible, no technology assumptions
Simple application
EAST - Class Diagram
Developer and customer created the UML diagram together.
EAST - Development
Archetypes content types with ZODB storage
UML modeling with ArchGenXML generating starter product
Security and UI refinements added (listing, search, reports, view)
EAST - Results
1 week to develop
2 content types, 23 page templates, workflow to track status
6 of 10 11/1/07 5:52 PM

7. Plone Application Development Patterns file:///Users/sek/tnc/naples/sallyk-slides/plone-patterns.html
Easy to maintain and extend
Big success with users!
Customer: quot;This has been my most pleasant development experience everquot;
EAST - ERA Page
Learning Lessons
Our technology choices had been haphazard
Need to base decisions on what works in our environment
Consistency
Repeatable development results
Application Patterns
Solution: define quot;application patternsquot;
A set of components, technologies, and tools
Used to create a certain type application
Good at solving certain types of problems
7 of 10 11/1/07 5:52 PM

8. Plone Application Development Patterns file:///Users/sek/tnc/naples/sallyk-slides/plone-patterns.html
In the context of our organization and level of development expertise
Pattern Definition - Problem
Internet or intranet
Type of information (spatial, structured, unstructured)
Sensitivity of information
Amount of information
Number of users, sessions
Organizational level (global, regional, local)
Community (conservation, marketing, finance, legal, etc.)
Pattern Definition - Technology
Components
GIS, web, database, ORM, search, authentication, user management, security, workflow, error
handling, logging, help system, etc.
Platform and toolkit
Development platform, language, testing frameworks, OS, etc.
Pattern Definition - Technology
Integration mechanisms
Web services platforms, enterprise search, etc.
Risks (security, business)
Cost
Plone Pattern - Problem
Intranet
Mix of structured and unstructured information, non-spatial or minimally
Non-spatial or minimally spatial requirements
(We use .Net framework with ESRI tools for spatial apps)
Suitable when information is restricted to authorized users/groups
Plone Pattern - Problem
8 of 10 11/1/07 5:52 PM

9. Plone Application Development Patterns file:///Users/sek/tnc/naples/sallyk-slides/plone-patterns.html
Small to mid size (up to thousands of objects, not millions)
Any number of TNC staff
Any organizational level or community
Plone Pattern - Technology
Non-spatial or embedded maps only
LDAP authentication
Archetypes, ArchGenXML
Plone Pattern - Technology
ZODB storage unless special circumstances
Extra cost for RDB must be justified
MySQL supported - but not Oracle???
When Is RDB Storage Justified?
Good reasons:
Legacy data that can't be moved
Simultaneous access from other (legacy) tools
When Is RDB Storage Justified?
Bad reasons:
Faster, more stable than ZODB
Making reports with Crystal Reports etc.
Ad hoc SQL queries by power users
=> Provide capability to periodically load data into the RDB
How Fast Can We Make One?
9 of 10 11/1/07 5:52 PM

10. Plone Application Development Patterns file:///Users/sek/tnc/naples/sallyk-slides/plone-patterns.html
90 seconds at 900 degrees F (485 C)
http://www.fornobravo.com/vera_pizza_napoletana/pizza_napoletana.html
Pretty Fast...
15 days to produce application with ZODB storage given UML diagram produced jointly by customer
and developer with up to
5 content types, 1 custom view per type
5 reports and/or custom search pages
Standard editing pages
6 custom permissions, 2 custom roles, 1 custom workflow
Plone Pattern - Cost Caveats
Predictable cost requires:
Use of shared product providing common elements
LDAP setup
Provide application mixin class with common behavior
Customize portal look and feel
Better for users as well as developers
Acknowledgements
Eric Coffman, lead developer on these projects
Questions
10 of 10 11/1/07 5:52 PM