Plone Application Development Patterns

Plone fest continues here in Naples. Sally Kleinfeldt from the Nature Conservancy is presently giving a talk about the ways their organization approached Plone development for their custom application development.

The Nature Conservancy is an environmental nonprofit protecting ecologically important lands and waters. They take a science-based approach and have protected 117 million acres. They have 1 million members, work in all 50 states and 30 countries and have 3,000 employees.

They have a traditional IT shop, supporting different departments, They also create custom applications for the conservation work. You can't buy these sorts of things off the shelf. They adopted Zope in 2000 to develop Nature.org and their intranet and they did their Zope development through the web.

In 2004 they moved to Plone for ConserveOnline.org (public community sharing portal). They did filesystem development with RDB or ZODB storage.

They build spatial and non-spatial apps with a mix of data and content. Users, roles and permissions are important. Workflow is sometimes important. There was an increasing need for custom applications for conservation and cross-application integration.

Example 1 - The Wrong Way

ConPro - a system to manage structured and unstructured information about their conservation projects.

Information was previously managed in complex Excel spreadsheets and associated documents, often in the field. There was a need for import, export, versioning, locking, security and search.

A large requirements phase was undertaken. There were 50+ pages of functional requirements - and this took 6 months to make. There was an automatic assumption of relational storage for ad hoc SQL queries. A spreadsheet was made for this project, and that spreadsheet dictated the data model. End users defined edit screen mockups based on the spreadsheet, and they wanted it to “work like Excel”. The requirements for versioning, security and workflow were fairly vague at this point as the users weren't really sure what they wanted or needed.

The developers knew they wanted to work with Plone for its compatibility with the ConserveOnline project. However, they were unable to hire an expert consultant to guide development (due to internal constraints) and they didn't have a lot of internal knowledge. The team they put together put a couple months of efforts into developing the spreadsheets, import/export, SQL methods, and edit forms. The design of classes, security, overall application were left until the end.

Archetypes was used for object security (stub objects). The rest was hand-crafted SQL methods and page templates. They didn't use workflow. Of course, the users changed their minds in the middle about the data model. They found a couple Plone experts to come in and help get it done.

Results: The project was late and overbudget. It took 30 person-months of effort. They produced roughly 400 hand-written SQL methods. They wrote 50 hand-written edit, display, report forms. Ad hoc SQL queries, which was supposed to be a major feature and the primary reason relational storage was chosen, was never implemented (and nobody ever cared or complained). The application was really difficult to maintain and extend. But…. this was a BIG success with users!

Lessons Learned:

Plone Application Development Patterns

\nPlone fest continues here in Naples. Sally Kleinfeldt from the Nature Conservancy is presently giving a talk about the ways their organization approached Plone development for their custom application development.

Are you hiring?    Post your job today ($45 for 45 days)!