A case study describing the Euphorie application. Euphorie combines many different types of technology in a single Plone site: dexterity content types, SQL stored content, custom traversal, sphinx documentation and even a grok application.

Euphorie: operational risk assessment tool. Identify risk in your organization and how to take them away. Does this at a European level. Developed by Syslab, TNO, Simplon (myself). Ambitious projects. 27 languages, 20 countries.

We wanted something that is easy to learn, use and extend, maintainable, scalable. Clean, documented, tested code.

It was not a very Plonish problem. So we unploned plone: no redirect tracking, no content rules, no sharing tab. Fairly simple to do.

Content types: archetypes has several problems, one of which is that it is slow. So we used dexterity, which has fewer problems.

In this project we do some very interesting things with Plone. One is dexterity. Another is the input we receive. A lot comes from Word documents, or the user added styles or linebreaks himself. So we had to do some cleanup work there.

HiFi (high fidelity) prototyping for the design in static pages. It at least allows you to share the css and javascript between the prototype and the actual implementation.

Grok-in-Plone. We basically built a grok site inside Plone.

We had to render our content in three different phaes. For the same risks we needed different forms. First: do we run this risk, yes or no; then: how likely is this; then: what are you going to do about it. So we did some url tricks by inserting 'PathGhosts' in the acquisition chain that added a string to the url although the actual object behind the url was still the same. So that got us saner urls.

Session content. The zodb is not fast at writing lots of content. But that was needed for storing the answers the user gave so far in the survey. So we used SQL here, using SQLAlchemy. And we put the user objects in SQL as well.

For documentation we added sphinx to all the packages.

Plone can be fun if you step out of the box.

New python frameworks such as pylons, bfg, grok, django take some different approaches than the Zope2 model Plone is based on. This talk will give a brief overview of other frameworks and the lessons that can be learned from them.

Geared towards developers this presentation walks you through developing a simple Plone 3 product using a test-driven or test-first approach. Techniques covered include unit testing, PloneTestCase, test layers, mocking and more. This is an updated and expanded version of the talk "Hone Your TestFu" given at the Plone Symposium East 2009.

I am using Plone since version 1.0. Senior consultant and founder of Scryent, in Toronto, Canada.

Slides are at http://tinyurl.com/pttt-slides

You don't always have to test. Sometimes you are just doing a prototype. But in my opinion: if you write production code, you should write tests. It improves code quality; reduces defects; makes your code more maintainable; it nudges you into more modular, loosely coupled code as that is easier to test; it keeps you focused: if the tests pass then you are done; when you have good test coverage, you can refactor with confidence.

Test first: write the test first, then start coding. It forces you to think about requirements up front. And manual testing is slow and error-prone.

Test levels: functional/system (black box), integration (your code in combination with Plone), unit (just your code).

More tests is not always better. Those tests need to be maintained too. With too many tests, it may start taking too long to run all the tests. Focus on lots of lower level tests as they are fast to run.

Unit tests: written from the developer's perspective. Test your components in isolation; use mocking techniques when you need to test integration with other components.

When working on a particular problem, try running only the immediately relevant tests. Try bin/instance test --help for some options you can pass. When those tests pass, run all tests again to check for unexpected failures.

Integration tests: test the integration of your code with Plone. Can you create the content types you made in the actual Plone Site? Do the correct values end up in the portal_catalog? Are the extra roles you defined actually added when you install your product?

Recently I started using collective.testcaselayer to simplify test setup. It simplifies repetitive Plone testing boiler plate.

Add it in your setup.py in extras_require and tests_require. Then in the eggs of your buildout add your.package[tests].

Use roadrunner to speed up testing: it sets up the layers (the Plone Site) and keeps that available so the setup is much much faster the next time you run those tests. There are some problems with for example z3c.autoinclude. I want to sprint on roadrunner this weekend.

Doctests look like interactive python sessions with documentation/explanation added.

Functional and system tests: end-to-end tests, black box tests, often zope.testbrowser tests, or with Twill or Selenium. Perhaps smoke tests: add specific tests for the most important paths that are used in your Plone Site. Twill is a domain specific language for performing web tests. It also provides a python API.

Use mocking to e.g. patch the time.time method, or urllib, or the MailHost. Martin Aspeli created plone.mocktestcase.

Coverage: answers the question: are all code paths executed in the tests. Does not guarantee that there are no bugs in the code. Use z3c.coverage to get html reports of the coverage.

Write tests at the lowest lelel possible. Take your time, write out what you are trying to do in English first. Is it too hard to test, then simplify your code, split it out.

I want to have an open space on testing.

Rok Garbas talks about the z3c.form form framework. Everybody is talking about is, using it, so it is time you learn how to (ab)use it and step into the Plone future. Tricks and things you might want to hear again. I won't speak about the internal structure, or why you would want to use it, or compare it with other frameworks.

For code examples, see his talk once it is uploaded to the Plone Conference 2009 website.

On the form you can set ignoreContext and ignoreRequest to control whether the form displays any values and where it gets it from.

Don't forget to package="plone.app.z3c.form" /> in your zcml when you use z3c.form in Plone.

You can register zope vocabularies and use that in your forms.

You can change the form layout. For that you create a layout factory, inheriting from plone.z3cform.templates.ZopeTwoFormTemplateFactory.

You can define your own widgets, for example to combine three inputs into one field.

You can create a custom data converter. It converts from the field to the widget (e.g. split fullname field into first name and last name inputs in the widget) or the other way around.

Within the form normally the default widgets are used. If you want to use your own widgets, you need to override the widgetFactory for that field in the form definition.

You can create group forms, which can be compared to Archetypes forms with tabs. Inherit from z3c.form.group.GroupForm.

In form wizards you can combine steps, so you can link different forms. Use collective.z3cform.wizard.

For more information, see http://docs.zope.org/z3c.form and http://pypi.python.org/pypi/plone.app.z3cform

Read Rok Garbas blog.

Alan Runyan is not here because he just had a baby (applause). The first South American Plone conference will be held this year.

Plone Foundation has been kicking ass this year; Jon Stahl did good work there (and is also having a baby). A lot of money was raised and spent to help more core people go to other conferences, also bigger industry events to represent Plone. Also some packages have been relicensed to make it easier to use them in other projects. Hosting of http://plone.org is now done by Six Feet Up. We are putting money into paying people to go to sprints. Dogin more marketing and evangelism.

Plone 4 is estimated to be released at the end of 2009. Release manager is Eric Steele. An amazing 26 new features (plips). We hope to have an alpha release at the end of the conference. It is the "Snow Leopard" of Plone releases, fixing lots of stuff in the background. Speedup, blob file storage, better memory management (partly because of using python 2.6), scales better.

Plone 5. Expected mid 2010 (well, maybe). I see Hanno Schlichting smiling, the release manager. Focus areas:

• Approachability. New content framework: Dexterity; but Archetypes is not going away. Dexterity is thorugh the web schema editing, with round trip support. Theming has become too hard; Deliverence: theming done right. We will use xdv for this. There will be talks about Deliverance this conference. We use this on the http://plone.org website already, so we believe in this.
• Plone needs to be faster. Partly we do this by using less code, Plone trunk plus all dependencies was at some point about 800,000 lines, instead of the 1 million lines of Plone 3.2. Using Chameleon for templating will make Plone faster. You can already use that on Plone 3.3 today. So more speed coming to you soon. We are going to run performance tests to see if Plone is not suddenly getting slower without us noticing.
• Simplicity. New layout system called Deco. It is a new approach to page editing. You will have page layouts composed of tiles, small boxes of text, images, lists, forms, polls, anything. "Tiles are the new apps." Where you would currently create a new content type you could probably create a new tile instead.

Deco: full page editing interface. What you edit is what you get. Separates layout from format. There will be no need for grid management, so not something like "add a row", "add a column". (Alex now does a Deco demo. Hey, Plone has a pony!)

Opportunities. Plone 4 and 5 are solving some basic problems. I want us to change the world again. Community: we want new talent, new web sites, new add-ons; it should be easier to get more people involved in Plone. We are not doing enough shouting from the roof tops. We know some of the weaknesses of Plone so we keep quiet; but all other system have their weaknesses as well. Be proud of Plone! What is our identity? Collaboration? Publishing? Simple apps? Using something like Amazon EC2 will help us as it makes it easier to run a Plone site. It should be simple to create small applications with Plone; Dexterity should help there. Going after Drupal, Wordpress we will lose, as they will always be cheaper. We are more up against frameworks like Alfresco and Documentum.

The Plone software needs to be more performant, self-documenting (sphinx, amberjack), more quality assurance (I will be running my blog on Plone 4 and when that is stable enough I will switch to Plone 5; the site might be down sometimes, but that is okay, it makes Plone better).

Be great. Talk more about Plone. Improve http://plone.org. It used to be a great driver of innovation.

Widen participation. Please start a Plone user group in your area. Evangelize Plone. It's all about you. Thank you for making Plone better!

Don't just complain. Complain and then try to make it better.