You're reading from Professional Plone 4 Development Build robust, content-centric web applications with Plone 4.

Product type Paperback

Published in Aug 2011

Publisher Packt

ISBN-13 9781849514422

Length 516 pages

Edition 1st Edition

Tools

Plone

Concepts

Front End Web Development

Table of Contents (6) Chapters

Preface

I. Getting Ready

II. Customizing Plone FREE CHAPTER

III. Developing New Functionality

IV. Real-world Deployments

Index

Chapter 1. Plone in Context

Since its humble beginnings, Plone has grown from "just another open source Content Management System" into a platform from which many people make their living, with hundreds of service providers worldwide. Big and small businesses, NGOs and charities, governments and individuals are building websites, intranets, and specialized applications on top of Plone with great success.

Spurred by advances in Python and Zope, along with increased media attention and recognition, Plone has steadily improved over the past several years. Plone 2.1 (released in 2005) and Plone 2.5 (released in 2006) were largely focused on incremental improvements and laying the foundations for future leaps in functionality. Plone 3.0 (2007) brought not only important new features to put Plone on par with most "enterprise" web content management systems, but instigated a more mature development process that led to incremental improvements through versions 3.1 (2008), 3.2 (2009), and 3.3 (2009). Plone 4 sets a new benchmark for stability and scalability, improves end user experience with a new theme and new visual editor, and brings Plone up-to-date with the latest Python and Zope releases.

In this chapter, we will:

Consider how Plone fits in with the ongoing evolution of Zope, and how the Zope Toolkit and newer Python technologies are changing web development practices
Consider when Plone may be a good choice for solving your web development problems
Discuss why and how you may want to become a part of the Plone community

A brief history of Plone

Plone is an application that runs on the Zope 2 application server. By now over a decade old, Zope was probably the first open source application server. It started life as an environment in which power users could build web applications through-the-web, and was at one point the "killer application" for the Python programming language. It has inspired various other applications and frameworks, as well as improvements in Python itself.

Zope 2 turned out to be a good platform for building content management systems, and the Content Management Framework (CMF) was created to make this easier. The CMF changed the emphasis of Zope programming towards filesystem-based development and applications that could be more easily packaged up and redeployed. It also brought us "tools", "skins", and many other concepts fundamental to Plone.

Plone was born as a user-friendly CMS using the CMF. It was initially a night-time collaboration between Norwegian Alexander Limi and Texan Alan Runyan, but other Zope and Python developers soon began to contribute as well.

As the Plone project built ever more functionality on top of Zope 2, the Zope developers were working on a successor, to be named Zope 3. This project aimed to start with a clean slate, drawing on the experiences (and mistakes) of Zope 2 and CMF to create a next-generation web development framework.

The main premise of Zope 3 was that small, reusable, easily testable, and well-documented components should be orchestrated into complete systems. The individual building blocks should also be usable from other Python applications. Eventually, the community realized that Zope 2 could become just such an application. By way of a piece of integration code called Five (hint: what is Zope 2 + Zope 3?), it became possible to use Zope 3 components and concepts directly in Zope 2 applications, including Plone.

Zope 3 and Five revitalized Zope 2 development. Zope 2.8 shipped with the components from Zope 3.0 as an add-on library. Subsequent versions continued to update parts of the Zope 2 internals with more modern components, in tandem with the evolution of Zope 3 itself.

Unfortunately, this co-mingling of Zope 2 and Zope 3 quickly became confusing, and Zope 3 never really took off as a standalone framework in the same way that Zope 2 had, not at least because by this time there were so many other Python frameworks to choose from.

In 2010, the Zope community decided to rebrand the "core" part of Zope 3 as the Zope Toolkit, or ZTK for short. The ZTK is used by a variety of applications, including Zope 2, and is advanced jointly by the developers of those projects. The application server and framework aspects of Zope 3 were moved out to a separate project called Blue Bream, which thus became another consumer of the ZTK. The name Zope 3 was retired, although you will still see it used in older documentation and code.

What is new in Plone 4?

The first edition of this book covered Plone 3. This edition has been updated to take into account new and changed components that come with Plone 4, as well as evolution in Plone 'best practice' over the past few years.

Some of the more exciting new features in Plone 4 include:

Plone 4 uses Zope 2.12 (up from 2.10) and Python 2.6 (up from 2.4). Plone 4.1 updates Zope to 2.13.
Binary files and images are now stored in so-called BLOBs by default, making Plone much better at serving large files.
There is a new default visual theme, known as Sunburst.
The default visual content editor has been changed from Kupu to the widely used TinyMCE editor. This is both better maintained and easier to extend, and should provide an improved user experience for content authors.
Plone's core JavaScript functionality is now based on jQuery and jQuery Tools. The most obvious change is that many features are now presented in modal "overlay" dialog boxes.
Portlet management has been improved with a better user interface for "blocking" portlets and per-group dashboard portlets, in addition to per-user ones.

It is now possible to let users log in with their e-mail address instead of a Plone-specific username.

By the time you read this book, Plone 4.1 should be out. This includes many incremental improvements, such as:

A new Site Administrator role, for users who should be able to administer the site without having access to the lower-level developer- and system administrator-oriented tools in the Zope Management Interface.
Better support for commenting on content, including moderation and Catpcha support, based on the new plone.app.discussion package.
Inclusion of a new HTTP caching tool, plone.app.caching.
A new standard approach to assign and look up universally unique identifiers (UUIDs) for content and other objects, based on the plone.uuid package.
Integration into the core distribution of the form building tool z3c.form, which we will cover in Chapter 11, Standalone Views and Forms, the testing framework plone.testing, which we will use throughout the book, and plone.app.registry, which is used to manage site-wide settings and preferences. In addition, the lxml XML parsing library will be bundled with Plone's installers to simplify installation.
Factoring out of some dependencies, so that it is possible to deploy a minimalist Plone installation without such things as the KSS Javascript framework, the Kupu visual editor, and OpenID support. The installers and standard distribution will continue to include these, of course, but by depending on the Products.CMFPlone distribution instead of the fully fledged Plone distribution, we can choose to only include those add-ons we need.

For more details, please see http://plone.org/products/plone/releases/4.0 and http://plone.org/products/plone/releases/4.1.

Note

We will use Plone 4.1 as the basis for the examples in the book, but we will highlight where there are differences between Plone 4.0 and 4.1 and how you can stay compatible with both releases.

Plone-the-application and Plone-the-framework

New users sometimes appear on the Plone mailing lists asking for a comparison of Plone and PHP, the popular web programming language. On the face of it, this is a strange question, if you consider that PHP is a language and Plone is first and foremost a content management application. You can download Plone, put it on your server, configure a few options, perhaps install a third party add-on product or two, and use it to solve your everyday content management needs.

Thus, "Plone-the-application" is used to power intranets, public websites, document repositories, and a host of other web-based systems. Plone successfully competes in the "upper mid-tier" CMS market, and is often chosen over commercial systems such as OpenText RedDot and Microsoft SharePoint in head-to-head evaluations.

Plone is developed almost exclusively by volunteers. It is open source, which means that you can obtain and use it for free, and that you are free to modify the underlying source code. There is no official, commercial "high end" version. There is no single company behind Plone selling support or certifications (although professional support is available from a multitude of smaller vendors). There is no specific hardware tie-in. So why have thousands of man-hours gone into making Plone an ever more sophisticated CMS?

The answer is two-fold. We will consider the community drivers later in this chapter, but there are strong commercial reasons as well. The majority of Plone's core contributors make their living from what is often referred to as "Plone-the-framework". They are professional web developers who sell consulting services and support, and have found that by working off an advanced, common base platform, they can offer better value to their customers. A few Plone contributors work for companies with large Plone installations that have found paying someone to spend part of their time contributing to Plone and getting changes into the core to be cheaper than buying ad-hoc support and development resources.

This model is of course nothing new in open source, but it happens to fit content management systems quite well. Customers rarely need a CMS as it comes out of the box. Most will want to customize its look-and-feel, workflow, security, and site structure. Frequently, customers also need some integration with existing systems, or may wish to build a portal that includes not only web page content, but various interactive tools and mini-applications.

If a customer is going to pay for consultants or developers to create the system they need, buying an expensive software license as well seems unnecessary. Developing a complete system from scratch is normally prohibitively expensive and risky. Better then, to take a system which comes close to meeting their needs, turn off the parts that are not relevant, and add the pieces that are missing. That is where Plone comes in. Customers can also take comfort from the fact that there is a large community of companies and individuals who can work with Plone. They need not be locked into a single vendor.

Because the people who build Plone spend the rest of their time building these more specialized systems on top of it, Plone's architecture has evolved in such a way that it is easy to extend. Indeed, this kind of extensible application is how Zope 2 (the application server on which Plone runs) was originally marketed. Almost any part of Plone can be amended, changed, or modified in such a way that Plone itself can be upgraded later without needing to reapply changes to the actual code base. That is, you should never have to fork Plone for your own needs.

Additional considerations when deciding on Plone

Whether Plone is a good base for your application or not will depend on how much Plone offers you out of the box, and how difficult it will be to provide the rest. Usually, this means that your requirements can be modeled in a "content-centric" way, making use of Plone's infrastructure for managing hierarchical, semi-structured content. Being able to reuse Plone's workflow-based security model, tried-and-tested user interface and its infrastructure for things like user management, page layout, and administration tasks also tends to be a strong selling points. Furthermore, Plone's strong support for internationalization and localization is an important consideration for many users.

At the same time, it is important to realize that to get the most out of Plone, you will need to make an investment of time, money, or both. Zope and Plone are RAM-hungry and run best on a modern server. Proper infrastructure is never free, and requires some planning. Similarly, if this is your first Plone project and you are intending to customize Plone extensively, you should bear in mind that there will be a learning curve. Besides online documentation and books such as this one, various companies also offer training courses and specialized consultancy, should you need it.

Licensing

Most parts of Plone are licensed under the GNU General Public License (GPL) Version 2, with various components alternatively licensed under the Lesser General Public License (LGPL), MIT, and BSD licenses. You should seek qualified legal advice if you are concerned about the license.

In practical terms, the license means that you are free to modify and reuse parts of Plone for your own needs. However, if you build a custom application on top of Plone and you intend to distribute (for example, sell a license for, or a boxed version of) that application, you will need to distribute its source code as well. You do not need to make the source code available if you are simply deploying a solution on an internal server.

Plone's source code is legally owned by the Plone Foundation, and is protected by a contributor agreement drawn up with the aid of the Software Freedom Law Center. This "software conservancy" model is very similar to the framework used to protect the integrity of other major open-source projects, such as Apache and Mozilla. The Plone Foundation is able to negotiate alternative license arrangements in special circumstances. Please see http://plone.org/foundation.

Licensing

The Plone Community, and why you belong there

The word "community" permeates any discussion of what Plone is and where it came from. In practical terms, Plone may be a piece of software, but in the truest sense, Plone is first and foremost a community. In the words of former Zope Corporation CEO Paul Everitt:

"Plone, the software is an artifact of Plone, the community."

Almost all of Plone's core contributors are (or become) friends in real life. They arrange "sprints"—short, intense development sessions—sometimes in exotic locations like an Austrian castle, a former military base on a Norwegian island, and a cabin high up in the Alps. There is an annual conference and usually a symposium or two throughout the year. And every day, the developers meet in online chat rooms and on mailing lists.

This friendship and the mutual respect that developers have for each other, are important factors contributing to Plone's success. Many of us care quite passionately about making Plone the best it can be, and happily expend both personal and professional time on Plone-related activities without direct financial reward.

The Plone community itself is larger than just the two or three dozen core developers, though. First, Plone's sister communities—those of Zope, CMF, and Python—overlap with the Plone community and with each other in socially complex ways. Second, a large number of developers contribute third-party add-on products, answer questions from end users and other developers, and participate in discussions around the future of Plone. A larger number still are end users and Plone administrators, reporting bugs, offering praise and criticism, and joining in the discourse. This is where we hope you will connect with the community initially, if you have not done so already!

Most open source communities have a core of dedicated developers with some governance structure around it. In Plone's case, governance is provided by:

The Plone Foundation, which is responsible for legal affairs and has a mission "to protect and promote Plone."
The current Release Manager, who has the final say over what goes into a particular release. A release manager typically serves for one or two releases, before handing over the reins (and serving as a mentor) to the next release manager.
The current Framework Team, who reviews contributions and make recommendations to the release manager during the early stages of the release cycle.

In practical terms, however, Plone's governance is extremely democratic, and there is very little conflict and very few emotional disputes.

Because of this, people generally find the Plone community open and approachable. Most developers are very happy to give help to those who ask for it, and questions on the mailing lists and in the chat room (see http://plone.org/support) are normally answered quickly. Many developers will also actively seek to involve more peripheral members of the community in improving Plone, for example through mentoring or invitations to sprints and other events.

One of the best qualities of the Plone community is its openness to new contributors and the deliberate way in which it develops new leadership from within. The users and developers which encircle the core will sometimes move closer to it through their own learning and participation. As they gain the trust and respect of other developers, they are given more decision-making powers and less supervision, and will be able to influence the future direction of Plone more directly.

Such influence is one strong benefit of actively engaging with the community, and it is not as difficult to attain as one might think. The main factor is attitude, not knowledge. For example, there are many people close to the core of the project who are less technical, but who want to help where they can. Ultimately, Plone would not survive without an influx of fresh blood and new perspectives from time to time.

Even if you are not enticed by rewards of responsibility and influence, being a member of the Plone community, however peripheral, will almost always be beneficial. By reading the mailing lists, for example, you will pick up much up-to-the-minute knowledge that may not be readily available elsewhere. When you are stuck, asking a question in the chat room or on a mailing list can often get you an answer in minutes or hours. By meeting Plone users and developers in real life, at user group meetings, sprints, conferences, and symposia, you will find yourself with a growing network of experts to draw upon when you need it the most. Save for Alan and Alexander, who started it all, every one of us was once a Plone newbie—many of us more recently than you might think!

Contribution to the community should be fun, fit your skills and interest, and give you something back. The easiest way to make a contribution is simply to start answering questions on the mailing lists. If you have some code you want to write, ask about how it may fit with existing projects, and how you may best contribute it to the community. If you feel there is a gap in the documentation and you would like to write a how-to or tutorial, you can do so at http://plone.org/documentation and submit it for review. If you would like to host a user group meeting or a sprint, get in touch! You will find that if you show a willingness to give a little, you will get a lot.