31,19 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Plone is an open-source content management framework, built on the top of the Zope application server and written in Python. As a ready-to-use Content Management System with a focus on usability, Plone makes it easy for content authors to create and edit web content. Plone is also used by developers, as a framework for building content-centric web applications such as dynamic websites and intranets. This book focuses primarily on the developer-oriented aspect of Plone.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 503
Veröffentlichungsjahr: 2007
Ähnliche
Table of Contents
Professional Plone Development
Martin Aspeli
Professional Plone Development
Copyright © 2007 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, Packt Publishing, nor its dealers or distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: September 2007
Production Reference: 1190907
Published by Packt Publishing Ltd.
32 Lincoln Road
Olton
Birmingham, B27 6PA, UK.
ISBN 978-1-847191-98-4
www.packtpub.com
Cover Image by Vinayak Chittar (<[email protected]>)
Credits
Author
Martin Aspeli
Reviewers
Andrew Burkhalter
Jon Stahl
Marco De Vitis
Wichert Akkerman
Acquisition Editor
Nanda Padmanabhan
Development Editor
Rashmi Phadnis
Technical Editor
Kushal Sharma
Editorial Manager
Dipali Chittar
Project Manager
Abhijeet Deobhakta
Project Coordinator
Sagara Naik
Indexer
Bhushan Pangaonkar
Proofreader
Chris Smith
Production Coordinator
Shantanu Zagade
Cover Designer
Shantanu Zagade
Foreword
by Alexander Limi, co-founder of Plone
It's always fascinating how life throws you a loop now and then that changes your future in a profound way—and you don't realize it at the time. As I sit here almost six years after the Plone project started, it seems like a good time to reflect on how the last years changed everything, and some of the background of why you are holding this book in your hands—because the story about the Plone community is at least as remarkable as the software itself.
It all started out in a very classic way—I had just discovered Zope and Python, and wanted to build a simple web application to teach myself how they worked. This was back in 1999, when Zope was still a new, unproven technology, and had more than a few rough spots. I have never been a programmer, but Python made it all seem so simple that I couldn't resist trying to build a simple web application with it.
After reading what I could find of documentation at the time, I couldn't quite figure it out—so I ended up in the online Zope chat rooms to see if I could get any help with building my web application.
Little did I know that what happened that evening would change my life in a significant way. I met Alan Runyan online, and after trying to assist me, we ended up talking about music instead. We also reached the conclusion that I should focus on what I was passionate about—instead of coding, I wanted to build great user interfaces and make things easy to use. Alan wanted to provide the plumbing to make the system work.
For some reason, it just clicked at that point, and we collaborated online and obsessed over the details of the system for months. External factors were probably decisive here too: I was without a job, and my girlfriend had left me a few months prior; Alan had just given up his job as a Java programmer at a failed dot-com company and decided to start his own company doing Python instead—so we both ended up pouring every living hour into the project, and moving at a break-neck pace towards getting the initial version out.
We ended up getting a release ready just before the EuroPython Conference in 2002, and this was actually the first time I met Alan in person. We had been working on Plone for the past year just using email and IRC chat—two technologies that are still cornerstones of Plone project communication. I still remember the delight in discovering that we had excellent communication in person as well.
What happened next was somewhat surreal for people new to this whole thing: we were sitting in the audience in the "State of Zope" talk held by Paul Everitt. He got to the part of his talk where he called attention to people and projects that he was especially impressed with.
When he called out our names and talked about how much he liked Plone—which at this point was still mostly the effort of a handful of people—it made us feel like we were really onto something. This was our defining moment.
For those of you who don't know Paul, he is one of the founders of Zope Corporation, and would go on to become our most tireless and hard-working supporter. He got involved in all the important steps that would follow—he put a solid legal and marketing story in place and helped create the Plone Foundation—and did some great storytelling along the way.
There is no way to properly express how much Paul has meant to us personally—and to Plone—five years later. His role was crucial in the story of Plone's success, and the project would not be where it is now without him.
Looking back, it sounds a bit like the classic romanticized start-up stories of Silicon Valley, except that we didn't start a company together. We chose to start two separate companies—in hindsight a very good decision. It never ceases to amaze me how much of an impact the project has had since.
We are now an open-source community of hundreds of companies doing Plone development, training, and support. In just the past month, large companies like Novell and Akamai—as well as government agencies like the CIA, and NGOs like Oxfam—have revealed that they are using Plone for their web content management, and more will follow. The Plone Network site, plone.net, lists over 150 companies that offer Plone services, and the entire ecosystem is estimated to have revenues in the hundreds of millions of US dollars annually. This year's Plone Conference in Naples, Italy is expected to draw over 300 developers and users from around the world.
Not bad for a system that was conceived and created by a handful of people standing on the shoulders of the giants of the Zope and Python communities.
But the real story here is about an amazing community of people—individuals and organizations, large and small—all coming together to create the best content management system on the planet. We meet in the most unlikely locations—from ancient castles and mountain-tops in Austria, to the archipelagos and fjords of Norway, the sandy beaches of Brazil, and the busy corporate offices of Google in Silicon Valley. These events are at the core of the Plone experience, and developers nurture deep friendships within the community. I can say without a doubt that these are the smartest, kindest, most amazing people I have ever had the pleasure to work with.
One of those people is Martin Aspeli, whose book you are reading right now.
Even though we're originally from the same country, we didn't meet that way. Martin was at the time—and still is—living in London. He had contributed some code to one of our community projects a few months prior, and suggested that we should meet up when he was visiting his parents in Oslo, Norway. It was a cold and dark winter evening when we met at the train station—and ended up talking about how to improve Plone and the community process at a nearby café. I knew there and then that Martin would become an important part of the Plone project.
Fast-forward a few years, and Martin has risen to become one of Plone's most important and respected—not to mention prolific—developers. He has architected and built several core components of the Plone 3 release; he has been one of the leaders on the documentation team, as well as an active guide in Plone's help forums. He also manages to fit in a day job at one of the "big four" consulting companies in the world.
On top of all this, he was secretly working on a book to coincide with the Plone 3.0 release—which you are now the lucky owner of.
This brings me to why this book is so unique, and why we are lucky to have Martin as part of our community. In the fast-paced world of open-source development—and Plone in particular—we have never had the chance to have a book that was entirely up-to-date on all subjects. There have been several great books in the past, but Martin has raised the bar further—by using the writing of a book to inform the development of Plone. If something didn't make sense, or was deemed too complex for the problem it was trying to solve—he would update that part of Plone so that it could be explained in simpler terms. It made the book better, and it has certainly made Plone better.
Another thing that sets Martin's book apart is his unparalleled ability to explain advanced and powerful concepts in a very accessible way. He has years of experience developing with Plone and answering questions on the support forums, and is one of the most patient and eloquent writers around. He doesn't give up until you know exactly what's going on.
But maybe more than anything, this book is unique in its scope. Martin takes you through every step from installing Plone, through professional development practices, unit tests, how to think about your application, and even through some common, non-trivial tasks like setting up external caching proxies like Varnish and authentication mechanisms like LDAP. In sum, this book teaches you how to be an independent and skillful Plone developer, capable of running your own company—if that is your goal—or provide scalable, maintainable services for your existing organization.
Five years ago, I certainly wouldn't have imagined sitting here, jet-lagged and happy in Barcelona this Sunday morning after wrapping up a workshop to improve the multilingual components in Plone. Nor would I have expected to live halfway across the world in San Francisco and work for Google, and still have time to lead Plone into the future.
Speaking of which, how does the future of Plone look like in 2007? Web development is now in a state we could only have dreamt about five years ago—and the rise of numerous great Python web frameworks, and even non-Python solutions like Ruby on Rails has made it possible for the Plone community to focus on what it excels at: content and document management, multilingual content, and solving real problems for real companies—and having fun in the process. Before these frameworks existed, people would often try to do things with Plone that it was not built or designed to do—and we are very happy that solutions now exist that cater to these audiences, so we can focus on our core expertise. Choice is good, and you should use the right tool for the job at hand.
We are lucky to have Martin, and so are you. Enjoy the book, and I look forward to seeing you in our help forums, chat rooms, or at one of the many Plone conferences and workshops around the world.
— Alexander Limi, Barcelona, July 2007
http://limi.net
About the Author
MartinAspeli has been active in the Plone community since 2004. He has contributed a number of new features since then, including the Plone 3 Portlets infrastructure and the Content Rule engine. He served on the Framework Team for Plone 3.0, acting as the team's spokesperson.
Outside the Plone core, Martin is responsible for popular third-party products, such as Poi (an issue tracker), RichDocument (a document type with attachments and inline images), and b-org (a user and group management tool). He also looks after the PloneHelpCenter and PloneSoftwareCenter, which power the Documentation and Products sections on plone.org, respectively.
A frequent attendee at conferences and sprints, Martin has presented several well-received tutorials, such as "Rich Document—Creating Content Types the Plone 2.1 Way", "b-org—Creating Content Types the Plone 2.5 Way", and the "Testing in Plone" manual. Acting as the de facto head of the Plone documentation team for well over a year, he has witnessed an explosive growth in the documentation available for Plone. He frequently answers questions from new users and developers online, and is well aware of the more common stumbling blocks for new Plone developers.
Martin gained an MSc in Analysis, Design,andManagementofInformationSystems at the London School of Economics in 2005. His thesis was entitled: "Plone—a model of a mature open source project".
The author would like to thank: Alexander Limi and Alan Runyan for starting such an exciting project; Jon "Active Voice" Stahl for language and grammar review; Andrew "Awesome" Burkhalter for language and technical review; Marco "The Guinea Pig" De Vitis for being a sharp critic; Wichert "LDAP" Akkerman for technical review, invaluable tips on LDAP, CacheFu, and PAS, and for being a great release manager; Balazs "KSS" Ree for review of the KSS chapter; Philipp "Zope 3" von Weitershausen for guidance and an excellent book on Zope 3; and finally, to the Plone community for playing host to so many good friends.
About the Reviewers
AndrewBurkhalter lives in beautiful Seattle, Washington, and is employed at ONE/Northwest, an environmental nonprofit that helps other organizations use new tools and strategies to engage people in protecting the environment. In just over two years, Andrew has helped launch over 100 Plone-powered websites. He also co-founded the Seattle Plone user group and assisted in the running of the 2006 Plone conference in Seattle. When not doing Plone projects, he likes to spend time with his supportive wife, Sarah. Or was that the other way around?
JonStahl has over ten years of experience providing online communications solutions and strategies to social change organizations. Jon works at ONE/Northwest, where he has helped build a thriving Plone consulting practice and has been an activate participant in the Plone community since 2005. Jon was also the primary organizer of the high successful 2006 Plone Conference.
MarcoDeVitis lives in Rome, Italy, where he is getting a degree in Electronic Engineering while working freelance as a do-it-all computer guy. Keen on everything computer-related, with a sharp eye for detail and a passion for well-written language, he couldn't avoid falling in love with technical documentation, and has thus been translating and reviewing software localizations and manuals every now and then since 1997, often focusing on open-source projects. He enjoys listening to some good music while doing it.
WichertAkkerman has been active in the ICT industry for over 10 years. He is well known in the open-source community where he has had roles as Debian Project Leader and Plone 3.0 release manager. Currently he works is an independent consultant, specializing in Zope and Plone.
Preface
Plone is an open-source content management framework, built on the top of the Zope application server and written in Python. As a ready-to-use Content Management System with a focus on usability, Plone makes it easy for content authors to create and edit web content.
Plone is also used by developers, as a framework for building content-centric web applications such as dynamic websites and intranets. This book focuses primarily on the developer-oriented aspect of Plone.
Throughout the chapters, there is an emphasis on demonstrating key concepts with practical examples. The reader should be able to borrow from the examples to get up and running quickly, but refer to the explanations provided to fully appreciate what is going on under the hood.
The book takes a pragmatic approach, building a realistic example application based on a case study. The code for this application is included with the book, and should serve as a useful starting point and source of examples for the reader.
What This Book Covers
Chapter 1 discusses Plone's history and community.
Chapter 2 introduces a case study, setting the scene for the rest of the book.
Chapter 3 teaches you how to set up a development environment, using zc.buildout to orchestrate various dependencies such as the Zope application server and Plone itself.
Chapter 4 looks at the various ways in which Plone can be customized and issues a few warnings about the perils of relying too much on persistent through-the-web settings that are difficult to reproduce across environments.
Chapter 5 concentrates on creating a policyproduct to manage site policy decisions and configuration settings related to the case study application. This is expanded with new policies in nearly every subsequent chapter. This chapter also emphasizes the importance of automated unit and integration tests.
Chapter 6 explores Plone's security model, and makes the case for using workflow as the primary tool for implementing a security policy by showing how to install a custom workflow using GenericSetup.
Chapter 7 demonstrates how to safely test, install, and customize Plone add-on products.
Chapter 8 deals with re-branding the growing case study application with a custom theme. It illustrates how to customize style sheets, templates, browser views, viewlets, and portlets—all without modifying the source code of Plone itself.
Chapter 9 delves deeper into the nine core concepts underpinning Zope and Plone development. Some of you may find this chapter a little fast-paced at first, and you may want to go back to it when you have had more time to see the described techniques in practice in the subsequent chapters.
Chapter 10 dives into the most important skill Plone developers need: building custom content types with the Archetypes framework. Here we will also create a custom portlet using Plone 3's new portlets infrastructure.
Chapter 11 describes forms and other types of browser views in more detail. Here we will use zope.formlib to generate forms with minimal configuration in Python. We will also be looking at ways of managing page flow, including the older CMFFormController product, and creating viewlets—snippets that can be pluggedin to the standard user interface at various points.
Chapter 12 shows how to connect your application to an external relational database, using the SQLAlchemy library and a little bit of Zope glue. We will also be using some advanced features of the zope.formlib library to create a ticket reservations form and a Plone control panel to configure database connections.
Chapter 13 concentrates on how to manage personalized information, building a form and a portlet to track a user's preferred cinema.
Chapter 14 aims at improving the user experience of a few of the application's features by using KSS, the new AJAX framework adopted in Plone 3.
Chapter 15 describes ways in which the example application could be taken further and briefly covers issues of internationalization.
Chapter 16 shows how to move the example application from a development environment to a production server using ZEO (Zope Enterprise Objects) for improved scalability and resilience.
Chapter 17 describes how to configure Apache, the popular web server, and Varnish, a caching reverseproxy, in front of Zope, in order to improve performance, stability, and fault-tolerance.
Chapter 18 describes how to connect Plone to an LDAP repository providing authentication services and user properties.
Chapter 19 describes some tips on managing releases of a live application, and performing migrations.
Who This Book is For
This book is aimed at developers who want to build content-centric web applications leveraging Plone's proven user interface and flexible infrastructure.
Some familiarity with the Python programming language and basic web technologies such as HTML and CSS is assumed. Readers would also benefit from some prior experience with Zope or Plone, for example as site administrators or "power users".
Reader Feedback
Feedback from our readers is always welcome. Let us know what you think about this book, what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply drop an email to <[email protected]>, making sure to mention the book title in the subject of your message.
If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or email <[email protected]>.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Customer Support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the Example Code for the Book
Visit http://www.packtpub.com/support, and select this book from the list of titles to download any example code or extra resources for this book. The files available for download will then be displayed.
The downloadable files contain instructions on how to use them.
Errata
Although we have taken every care to ensure the accuracy of our contents, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in text or code—we would be grateful if you would report this to us. By doing this you can save other readers from frustration, and help to improve subsequent versions of this book. If you find any errata, report them by visiting http://www.packtpub.com/support, selecting your book, clicking on the Submit Errata link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata added to the list of existing errata. The existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Questions
You can contact us at <[email protected]> if you are having a problem with some aspect of the book, and we will do our best to address it.
Part I. Getting Ready
Plone in Context
The Case Study
The Development Environment
Chapter 1. Plone in Context
Over the past few years, Plone has grown from "Just another open-source Content Management System" into a platform, and 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 credibility, Plone has steadily improved over the past few years. Plone 2.1 (released 2005) and Plone 2.5 (released 2006) were largely focused on incremental improvements and laying the foundations for future leaps in functionality. Now, with version 3.0, Plone is once again delivering innovative and exciting new features.
In this chapter, we will place Plone in the context of modern web application development. We will consider how Plone fits in with the ongoing evolution of Zope, and how Zope 3 and newer Python technologies are changing web development practices. We will consider when Plone may be a good choice for solving your web development problems, and we will discuss why and how you may want to become part of the Plone community.
A Brief History
The history of Plone begins with Zope. Zope was, in the words of Paul Everitt, "the first open-source application server", and that is not the only way in which it was ahead of its day. Zope 2, on which Plone is built, started life as an environment in which power users could build web applications through the Web. It was at one point the killerapplication for the Python programming language, and has inspired various other applications and frameworks, as well as improvements in Python itself.
Note
See Phillip J. Eby's foreword to Philipp von Weitershausen's excellent book Web Component Development with Zope 3, also available at http://dirtsimple.org/2007/01/where-zope-leads-python-follows.html
Zope 2 turned out to be a good platform for building content management systems, and the Content Management Framework (CMF) was born to make this easier. Eventually, CMF began to change some of the emphasis of Zope programming towards file system-based development and applications that could more easily be packaged up and re-deployed. It also brought us tools, skins, and many other concepts fundamental to Plone.
CMF ships with an example portal application called CMFDefault. It is fair to say that CMFDefault is not the prettiest of systems, and it is not widely used except as an example. Plone was born to make CMF pretty and user-friendly. 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 Plone's potential became clear.
Zope old-timers sometimes joke that Plone is "just a bunch of skins". As Plone grew in scope, however, it gained a lot more Python code. CMF components were customized and new functionality was added. Somewhere along the way, the Plone community probably lost touch a little with the CMF community and ended up inventing things that would have been better placed "further down the stack" at the CMF level, for better or for worse.
At the same time, Zope mastermind Jim Fulton and his band of renegades were creating Zope 3. The main premise of Zope 3 is that small, re-usable, easily testable, and well-documented components should be orchestrated into complete systems. It should also be possible to use them inside other Python applications. One such application is of course Zope 2. Via a piece of integration code called Five (Zope 2 + Zope 3 =?), it is possible to use a large number of Zope 3 components and concepts directly in Zope 2 applications such as Plone.
Zope 3 and Five revitalized the development of Zope 2. Zope 2.8 shipped with the components from Zope 3.0 as an add-on library. Zope 2.9 followed soon after, incorporating Zope 3.2; Zope 2.10, on which Plone 3 is built, contains Zope 3.3.
At the same time, more and more parts of Zope 2, CMF, and Plone were (and still are) being rewritten to make use of Zope 3 concepts and, where applicable, existing Zope 3 components. Some predict that Zope 2 and Zope 3 will eventually converge, becoming two different configurations of the same application.
If you find this confusing, you are not alone. A common misconception is that Plone 3 will run in a pure Zope 3 environment. This is not the case; doing so would most likely require re-writing Plone from scratch, and would break every third-party product and customization in use.
Zope 3 is simply not an upgrade to Zope 2, but a whole new way of building software. Whereas Zope 2 is a fairly monolithic application server, Zope 3 aims to be a collection of components and of technologies for pulling those components together. There are some who feel that the name Zope3 is unfortunate, and it should have been named something else altogether, so as to not imply a linear progression from Zope 2.
Although it may be confusing, the mixing of Zope 3 into Zope 2 has had a profound impact. Almost every new feature in Plone 3 relies on Zope 3 technologies in some way. Several developers report being much more productive than before, and say that Zope 3-style programming makes Plone development more fun.
Further, Zope 3 has brought the developers of Zope, CMF, and Plone closer than they ever were. The Goldegg Initiative, a sponsored effort to improve Plone's framework stack in ways that most customers would not be willing to pay for, helped set off a snowball that has seen major improvements in community relationships as well as in the code itself.
At the same time, the wider Python community, which sometimes views Zope with some suspicion, has been developing great tools of its own that the Zope community is busy adopting. The most important one is perhaps eggs, a way of packaging Python libraries for easier deployment and dependency management, somewhat similar to Java JAR files.
Not far behind is WSGI, the Python Web Services Gateway Interface, which defines ways in which Python web applications written in different frameworks can interoperate at the HTTP level. WSGI thus promises to let developers stitch together complete systems from multiple specialized applications. Zope 3 already supports WSGI, and various projects are under way to explore ways to integrate it better with Zope 2 and Plone.
Competition
Zope had little competition when it was first introduced in 1999. That is no longer the case. Ruby-on-Rails is probably the best known of the new breed of rapid application development frameworks, but Python has a few of its own: Django, TurboGears, and Pylons to name a few. Zope may go head to head with these through a new and exciting project called Grok, which aims to bring techniques such as convention-over-configuration to Zope developers by building a higher-level framework on top of Zope 3. Grok is not yet directly relevant to Plone development, but it is possible that Grok programming will one day be available to build Plone extensions.
The common theme running through all of these developments is greater interoperability. The Zope 2, Zope 3, CMF, and Plone communities are becoming more and more open to external influences, adopting code, standards, and tools from other projects and offering a few of their own in return. For example, the Twisted web server project uses Zope 3's zope.interface as its interface implementation, and Zope 3 is using Twisted's web server code to provide WSGI support.
The corresponding challenge is that there are many new tools and techniques with which Plone developers may want to be familiar. At the same time, some old tools and techniques have been superseded by new technologies. Keeping up with it all can be daunting. Hopefully, this book will help, by focusing exclusively on "new-world" techniques and current best practices.
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. That is pretty crazy 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 RedDot CMS 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 commercial "high-end" version (although Enfold Systems does offer a commercial version of Plone for Windows called Enfold Server). 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 a common base platform that is as good as possible, they can offer better value to their customers. A few Plone contributors work for companies with large Plone installations that have found that paying someone to spend part of their time contributing to Plone and getting changes into the core is cheaper than buying ad hoc support and development resources.
This model is, of course, not 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. At the same time, developing a complete system from scratch is normally prohibitively expensive and risky. Better then, to take a system that comes close to meeting their needs, turn off the parts that are not relevant, and add the pieces that are missing. This is where Plone comes in.
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 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 extended, changed, or modified in such a way that Plone itself can be upgraded later without needing to re-apply 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. (For more information, see http://plone.org/documentation/faq/is-plone-for-me.) 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 re-use Plone's workflow-based security model, its tried-and-tested user interface, and its infrastructure for things like user management and other administration tasks also tend to be strong selling points.
At the same time, it is important to bear in mind 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, you should bear in mind that there will be a learning curve. Hopefully, this book will prove a good investment. 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 re-use parts of Plone for your own needs. However, if you build a custom application on top of Plone and you intend to distribute (e.g., sell a license for or a boxed version of) that application, you will need to distribute your 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.
The Plone 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.
The Plone Community, and Why You Belong There
The word "community" permeates any discussion on 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 Paul Everitt, "Plone, the software is an artifact of Plone, the community."
Almost all of Plone's core contributors are 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 developers have for each other are important factors in 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. Firstly, Plone's sister communities—those of Zope3, Zope 2, CMF, and Python—overlap with the Plone community and with each other in socially complex ways. And secondly, a larger 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, reporting bugs, offering praise and criticisms, 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:
In practical terms, however, Plone's governance is extremely democratic, and there is very little conflict and very few emotional disputes.
Because of this, most people 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 Plone is its openness to new contributors and the deliberate way in which it develops new leadership from within. The users and developers who encircle the core will sometimes move closer to the core of the community 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 examples of people close to the core of the project that 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, becoming a member of the Plone community, however peripheral, will almost always be beneficial. By reading the mailing lists, for example, you will pick up a lot of 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 sometimes get you an answer in minutes or hours. By meeting Plone users and developers in real life, especially at user group meetings, 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 overlap 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.
Summary
In this chapter, we have learned:
In the next chapter, we will introduce the example application that we will use throughout this book.
Chapter 2. The Case Study
Throughout this book, we will build a semi-realistic application that demonstrates various Plone technologies and concepts. The source code for this application can be found on the book's accompanying website.
Note
Please see the README.txt file in the source code archive for more information on how the examples are structured and how to run them.
We will explain the various packages and modules over the next several chapters but if you are the type of reader who likes to start from the end, feel free to browse through the code now.
In this chapter, we will present the case study and our fictitious client's requirements, and do some high-level modeling of what the application may look like in Plone.
High-Level Requirements
Optilux Cinema Group is a mid-sized chain of cinemas. They currently have a limited web presence, but wish to expand it to offer movie-goers a better way to find out about the latest films and reserve tickets for screenings.
The following high-level requirements have been presented to potential vendors for the cinema's web application:
Requirement
Importance
Chapter
1
The site should have a look and feel consistent with Optilux's corporate branding.
High
5, 8
2
The site should show information about all of Optilux's cinemas.
High
7, 10
3
Non-technical cinema staff should be able to update information about each cinema.
High
7, 10
4
The site should allow staff to highlight promotions and special events. These may apply to one or more cinemas.
High
10
5
Cinema staff should be able to publish information about new films. It should be possible to update this information after publication.
High
10
6
Customers should be able to find out at which cinemas a particular film is showing, and which films are showing at a particular cinema. Note that the scheduling of films at cinemas is managed in an existing relational database.
High
12
7
Only films that are currently showing or will be shown in the near future should be viewable.
High
10
8
Customers should be able to search and browse films by cinema, location, date/time, or film name.
High
10, 12
9
Customers should be able to reserve tickets online. Tickets will be picked up and payment taken at the cinema. Reservations must use Optilux's existing relational database-based ticketing system.
Medium
12
10
Cinema managers should be able to view reports on reservations and site usage.
Medium
11
11
Customers should not need to log in to use the site, but a username and password should be required when they wish to reserve tickets.
Medium
12, 13
12
Logged-in customers should have easy access to their preferred cinema or cinemas, e.g. those in their area.
Medium
13, 14
13
Customers should be able to email enquiries to the site manager if they have questions or feedback.
Low
11
14
Customers should be able to discuss and rate movies.
Low
11, 14
15
The site should support cinema staff in developing future programming and promotions through a private collaborative workspace.
Low
13
As you become more accustomed to Plone development, these requirements will start to ring a few bells. For example, we may identify some custom content types by finding the nouns in the requirement descriptions (e.g., #2, #3, and #5), such as Cinema and Movie. We may be able to satisfy a few requirements by using Plone's standard content types or simple extensions thereof—a Promotion (#4) could be an extension of an Event or NewsItem, for example.
It is also very likely that the various content types will require custom workflows and security (e.g., #5, #7, and #15). We can identify user roles like Customer, Staff, and Management from the subjects in the various requirement descriptions, and start to understand what permissions these roles may have.
For reservations and reporting, it is clear that we will need some relational database connectivity (#9). This, in turn, will probably mean developing custom forms and templates that access the information in the database.
As the system requires management of member data and preferences (e.g., #11 and #12), we may need to add additional user properties. To support collaborative workspaces (#15), we may need advanced workflow and security policies.
Note
The terms member and user are often interchanged in the context of Plone. Registered users are often referred to as portalmembers.
Lastly, we must provide client-specific branding (#1). Plone can provide user-friendly administrative pages and content management operations. We may also want to use Plone 3's new AJAX framework, called KSS, to add dynamic, JavaScript-driven, user interface elements.
Modeling and Mock-Ups
As a developer you may, perhaps in conjunction with the client, decide to do some initial modeling of how the system may look. Some developers advocate very detailed modeling and strict adherence to relevant standards such as UML (the UnifiedModelingLanguage). This depends on personal preference. In the author's opinion, the models themselves are not as important as the actofmodeling—thinking through the client's requirements in terms of high-level components and interfaces.
Models can help structure a conversation with the client. Walking through a model often brings an abstract idea of an application to life. You may want to show screen mock-ups and design suggestions as well. These can give the client a more concrete idea of how the solution will look to end users.
For the purposes of this application, we will start by drawing a UML Use Case Diagram, which shows the main users of the system and the types of things they may want to do with it:
This diagram is by no means exhaustive, but it gives a quick visual representation of the kind of interactions the application will need to support.
From this, we can identify the major system components represented in a high-level Class Diagram as illustrated below. This also shows where external interfaces will be needed, in this case to the relational database holding movie reservations.
Tip
This is not, strictly speaking, a correct use of the UML class diagram syntax, but it is useful nonetheless.
Again, this diagram is far from exhaustive, but it shows that we will need to manage Cinema and Film objects, which are related by Screening instances. Customer and Staff are different types of site users. A Customer can make a Reservation for particular Screening. A Customer can also add a Rating for a particular Film. In the content collaboration system, Staff can be members of various projects, which contain Document objects that staff are working on.
We will also provide some design mock-ups, drawn in a graphics program, which give an idea about the end result's look and feel:
In Chapter 8, we will see how this mock-up forms the basis of a customer site theme.
If necessary, we could do much more detailed modeling, but this is probably more than enough to have a meaningful conversation with the client. Naturally, the system will evolve from these models, and may include elements we have not captured here.
Running the Project
Project management is certainly outside the scope of this book, and every developer and organization will have different ways of managing their development projects. It is probably fair to say, however, that most Plone consultants prefer to work according to agile principles (see http://agilemanifesto.org), which typically include rapid prototyping, short development iterations, and a high degree of customer interaction throughout the design and development process.
Indeed, Python is often branded as an agile programming language because it is quick to write, easy to read, and lends itself well to code refactoring. Furthermore, because Plone gives us a fully featured system out of the box, you will be able to have something tangible and usable up and running almost instantly, which you can incrementally refine with input from the client.
Many developers keep a live test server for the client to play with, periodically deploying code updates to showcase new functionality. If you go down this route, you will probably want to set up an issue tracker for the client to report any problems they find. You could even do this in a Plone site (probably not the same one that the client is actively trying to destroy, though), using something like Poi (http://plone.org/products/poi). Alternatively, there are many other stand-alone solutions—Trac (http://trac.edgewall.org) being a popular and Python-based one.
Getting a draft version of the client's desired branding available for testing quickly can be very valuable, as the client may have trouble making the conceptual leap from vanilla Plone to their own requirements. Even just putting a logo and color scheme into a site otherwise using the standard Plone theme can give the client a greater sense of ownership and generate some excitement. It is normally advisable to turn off core Plone functionality that the client does not need sooner rather than later, though, to avoid confusion.
As you work with our clients, you will get a better idea about what is important to them. Giving them what they want most first, getting them involved in testing early, and being receptive to the changes in the specification is usually a very good idea.
Because of this, many Plone consultants will work on a time and expenses basis and promise frequent code releases, allowing the project to grow with the client's understanding of their needs. This is not so different from how Plone itself grows as people discover new things they would like it to do. By following good development and project management practices, and effectively leveraging Plone's base functionality, you can ensure that at any given point in time, the client has a fully functional (but partially complete) application at their disposal for testing and experimentation.
Summary
In this chapter we have been introduced to:
In the next chapter, we will learn how to set up our development environment, before we start building the application for real.
Chapter 3. The Development Environment
Before we can start building our application, we should set up a suitable development environment. This should as closely as possible mirror the final live server configuration, so that we can test our software locally before deploying it. The environment should also provide appropriate tools to support us during development.
In this chapter we will learn more about the elements of Zope's software stack and how they can be configured for development. We will also cover some supporting tools and technologies, such as Python eggs and Paste Script.
Prerequisites
Pre-built packages for Zope and Plone are available for many operating systems. These can be tempting, but as developers it is normally better to configure the environment ourselves, in order to fully understand and control it. During development, we need write access to the Python code and configuration files. We may also need to run different versions of Zope and Plone in parallel.
We will assume that you have at least the following as part of your regular development environment:
