CHAPTER 12
Case Studies

We've almost gotten to the end of our journey, a journey that has let us learn about a very powerful CMS, as well as a flexible development environment. Throughout the previous chapters, you built an understanding, brick by brick, of all the basic concepts and features of Plone, and you started to build your personal experience as a user, integrator, and developer.

We will conclude the book with a dive into real life. In this chapter, we'll cover some of the most common cases that you may encounter in your experience as Plone webmaster or developer. We will cover many of the requirements that a business might have, and how Plone can meet them. This will also give you a further overview of what you can really do with Plone.

Some of the use cases we will face in this chapter deal with simple Plone configurations—just changing some settings in the Site Setup area provided by the default Plone user interface. You will see, for example, that to create an intranet for your company, if you don't have any special requirements to accomplish, you can simply go with a standard Plone installation, add some configurations about workflow and groups of users, and you're done!

Other use cases, however, will instead require solid Plone development experience. We will talk about writing ad hoc products and integrating other systems in our Plone site. The point will be always the same: Plone is not only a good CMS out of the box, but also a very flexible development framework and a powerful application environment. With it you will be able to meet almost all of your needs.

Finally, this final chapter has another aim: showing you where you can push your Plone experience to, so that you can continue learning and expanding your knowledge involving Plone. For this reason, this final chapter could be also be a good first chapter to read—it will keep clear in your mind why you are going to learn Plone.

Management of Enterprise Workflow

Let's try to start deepening your understanding of Plone versatility and examine a possible use case related to a realistic enterprise workflow. You'll find that in adopting Plone, you can easily solve various document-management needs of your department, and it will probably do its best just as it is, right out of the box.

Before going into specific cases, let's note some general features of Plone that make it applicable to several use cases. In Plone, you can easily create specific content types, or just use specific folders to separate different kinds of documents, as well as define various groups of users to delegate specific activities at your ease. Besides this, you can outline your own document workflow in minutes, with specific states and transitions, thus creating dynamic behavior for your content, the same way that the publication workflow that comes with Plone acts as a publication engine for its content. You can have all these with a basic Plone installation, and much more, as far as you can master the whole set of its features and capabilities. And of course you can! We covered all the features you need to build your information architecture in Chapter 3, and how to administer the site in Chapter 4. Furthermore, if you need to do some more complex configuration, you can refer to content types and indexing services in Chapter 5, customizing Plone's look and feel in Chapter 6, and advanced user management in Chapter 8.

Let's try now to push forward our use case a bit. Imagine we wish to support a specific enterprise workflow like the following: we have our operational data accessible and manageable through enterprise resource planning (ERP) software. Its standard workflow starts by focusing on an "order" document; when it is time to send it out, after some adjustments to its data through the ERP, we produce the order document, send it to our supplier, and store it in a specific shared folder.

Of course, in the middle, someone has to manage the order, receiving a request and looking for the right supplier and price; and then someone else will have to approve it; and finally some low-responsibility personnel will send it to the supplier by mail and fax, and properly store the document in the right place.

Here is where Plone can help in both organizing the workflow and suitably supporting a rational and efficient scheme for storage and retrieval of the yielded digital documents, and content in general.

If we have at our disposal a legacy ERP, such as any Oracle-based operational software or SAP, we can easily start generating the final document out of "raw" database information. Just create a relational view on your ERP database, where order data can be read by Plone, and then show this data to the user and let him select which order should be transformed (into, for example, a PDF document). To do so, you will have to pick some document-generating solution, like Reportlab (www.reportlab.org), or OpenOffice Python binding, to effectively produce the content file. This document could also be produced by the ERP itself directly: we could just save it into a shared folder and let Plone process any files it finds there (e.g., an OpenOffice document or a plain CSV text file).

At this point, we have a PDF or OpenOffice document in Plone, and we can easily attach to it some ERP metadata, like "Order Date" and "Order Number," to make subsequent classification and retrieval easy. We could set on it a specific order workflow diagram, including three states: to_approve, approved, and notified. Of course, we should let only a certain group of users approve the documents; besides, we should set the notification accordingly, so that the corresponding users have a simple-to-manage to-do list—for example implementing a dedicated portlet that shows all the documents that have to be approved or notified. To improve the support, we can set a mail notification system for orders, and that could be done directly through the Plone user interface, using the powerful content rule tool we discussed in Chapter 4, in the "Managing Automatic Rules" section.

We can easily imagine a more elaborate approval phase, where the user digitally signs the order document using a personal smart card and specific client software. In this situation, we could provide a special download link to make the digital signature software open automatically, and receive the signed files back into the system if the user saves them in some special shared folder. We could then recognize each file just by reading a special key in the uploaded file name, and link it to the original document to approve.

Of course, this workflow could be as complicated as you like. However, it should be clear enough by now that you don't have to think of Plone's out-of-the-box features as a cage, but rather as a proposed way to tackle content management issues "the Plone way" (and we know the Plone way allows us to meet nearly any need!).

Plone is very apt for these kinds of enterprise workflows. The more unstructured they are, the more easily Plone will succeed, as it gives you a strategic support environment through which you can rapidly improve the enterprise knowledge base (e.g., a Plone-based application can help you easily switch from share folders and personal mailboxes to a central and reliable documents repository).

E-Commerce with Plone: Your Business Online

You have learned how to build amazing web sites and provide good services to your users. Now it is time to get paid. Plone has a long history in business-oriented features, but the efforts have not been focused toward the creation of the typical monolithic e-commerce platform. Instead, the Plone way is to provide reusable and flexible modules that can be used in any site.

Integrating E-Commerce Functionality into a Plone Portal

This means that in your site you can take the classic approach of providing product catalogs and a cart for the buyer, managing payments, and so on. What you will have to do is integrate into your Plone site new functionalities through add-on products. You will also have to manage some complex cases. For example, say that what we are selling isn't a product with a simple material value. For instance, imagine a web portal that sells training; the primary purpose of the site is to manage courses and training materials, so it can't be designed for typical e-commerce. Instead of building a second site to sell these kinds of products, we can instead quite easily assign a price and number of available seats to our courses, so that users can put courses in their cart together with training materials, and this material can include both online documents and real books. After the payment, they obtain the access to the courses and receive the books. You can also set up a particular workflow for the online documentation, so that students can even fill in exercises and submit them, or propose changes (see Chapter 7 for more details on workflow).

Plone extends well to many other complex e-commerce use cases. For instance, if we deal with goods that have an expiration date for the user (suppose we also sell, for example, the right to view content for a certain amount of time), and we allow recurring payments (a sort of subscription), we can simply set the good so that when it expires, it will no longer be available to the user; you can simply use the expiration date feature Plone provides by default (see the "Setting Page Metadata" section of Chapter 3), or build an ad hoc module for more complex features.

This type of Plone setup is wonderful for the managers of the portal, because they can edit and manage all the course information in the same place and won't have to keep two different platforms aligned (one for the anonymous visitors, and one for subscribers). When a new course is ready and published, it will be also buyable. As you probably already know, you can build all this by creating a "courses" workflow, with new states and transitions.

Atypical E-Commerce Use Cases with Plone

In other cases, you may not need an e-commerce infrastructure at all, but you simply want to allow your users to give you money—for example, for a donation or to sponsor a project or an event. You do not need a cart and you do not need to record the details of your users. To achieve this with Plone, all you need are some pages that describe what you will do with the users' money and some fields to let users choose their type of donation, and then you can send everything to your payment gateway. You should be able to manage all this in a pluggable way. You can just start with PayPal, which has an efficient e-commerce service you can integrate into your site (visit the official site to see how to create a personal business account that accept payments on the Internet: https://www.paypal.com/us/cgi-bin/webscr?cmd=_registration-run), and then move to a bank so that your money transfers will be directly processed.

Another common use case that you can easily satisfy with Plone is the creation of a personal request for payment. It's simple: you can create invoice objects and share them only with the recipient, who can be a registered user. We have covered how to reserve content in depth in previous chapters (above all in the "Sharing Your Content" section of Chapter 3). For more complex needs, you can use a particular workflow policy (see the "Adding Plone Policy Support" section of Chapter 7).

You can even avoid the traditional login procedure, recognizing the user with a token (a long code that allows access to a nonregistered user) generated and sent by the system. In both cases, only the selected user will be allowed to see his invoice and pay it.

When all is said and done, using Plone for business does not require a different approach for your web applications. Its modular structure allows you to inject payment features into a live site.

It is even possible to use the same commerce tools and modules for other aims. For example, one interesting cross-application would be to have your users use the cart to select the most interesting content in your web sites, and then send you feedback or subscribe for changes.

Automatic Handling of Documents and Images

Throughout the previous chapters, we have emphasized a basic concept: Plone is not simply a CMS—it is a complex framework, a dynamic development environment that allows you to extend and customize features. In this section, in particular, we will cover the possibility of handling and publishing images and documents. You can easily perform these tasks with many CMSs, but with Plone you can also solve various complex use cases involving your document and image data. For example, you can add watermarks to images and allow for dynamic document generation from your web content.

We will briefly discuss these use cases and figure out a good way to meet our needs. But remember, there is always more than one solution that can meet a demand.

Watermarks on Images

Our first use case is the following: suppose we publish a rich photo gallery on our Plone site. The image content type is automatically published so that any anonymous visitor can view the images, and this is what we expect to happen. But what if we don't want people to be able to download them and use them in any manner they wish (e.g., publishing them on their own site without citing the source)?

To solve this drawback, you can integrate into your Plone site a product for watermarking, so that identifying information is embedded into the image's data. You can, for example, mark the images of your photo gallery with a copyright notice and/or a logo.

The watermarking can be automatically applied when you or a member of your site creates or edits an image, or just if the user decides to enable that feature. In addition, the watermarking can be performed with different styles—for example, transparency of watermarks, tiled watermarks, random or localized watermarks, staggered marks, and so on.

Implementing these features in your Plone site is not complicated, but of course you need to be familiar with the Python language and the structure of Plone: working with the Python Imaging Library (PIL, which is already installed with your Plone installation), you will be able to create an ad hoc product that will meet your needs.

Dynamic Document Generation from Your Web Content

This time, let's assume we have an e-commerce site; suppose we sell cameras, and we therefore have a Products section in our Plone site that contains a lot of objects—one for every product we sell—divided into categories. For each product, we provide the visitor with a data sheet with all the technical specifications.

Wouldn't it be great to give visitors the chance to download a PDF file that summarizes all the characteristics of the product, using a nice template with your logo and contacts, that you can customize, for example, on the occasion of periodic promotions? Even better, you could enable the possibility of downloading the entire product catalog!

With Plone you can realize this desire, and you can do it in different ways. There are various add-on products that let you export various types of Plone content to a PDF, DOC, RTF, or simple TXT document. The best thing you can do is write a product that lets you and your collaborators easily operate on the template to apply to the files that will be generated and exported. The user will just have to click a button you will add to the view of each product on your site, or to the view of the container that contains the entire catalog, to download, for example, a PDF file that they can easily consult offline or print.

Plone and Multimedia

As a CMS, Plone enables its users to upload and share any sort of binary file—this of course includes audio and video files. However, if you want to get more complex and use Plone as a specialized multimedia portal, you will need to handle some specific issues and requirements. We'll discuss some of the most common ones.

In a site that deals with multimedia content, we'll probably have to deal with some types of metadata that are not part of the Dublin Core set of metadata normally managed by Plone, such as metadata that involves resolution or codecs. Besides this, we'll also need some specialized preview mechanism, or, better yet, some streaming functionality—which introduces one of the biggest problems of multimedia: how to handle big files and long-running requests. On top of all that, we'll want to offer specialized features, such as podcasting or user tagging of multimedia content.

So, is Plone the right tool to achieve all this and more? Of course it is! But we will need to rely on some extension products if we don't want to write too much code on our own. And we will also need to choose a good deployment configuration for our service to enable the system to handle big files and long-running requests.

The first and most important set of products for multimedia handling in Plone comes from the Plone4Artists project (see www.plone4artists.org and http://plone.org/products/plone4artistssite), supported by Jazkarta, which aims to strengthen Plone to become the perfect artist community web site. Plone4Artists provides us with some new content types to handle audio and video files in the ways that we expect.

For every type of file we will upload, the system will recognize it and will make it act in the proper way. So, for example, if we add a video file to our Plone site, Plone will extract its proper metadata automatically, and will show the player on the default view page. If we add a link object with a URL pointing to a video file on YouTube, Vimeo, or other common video-hosting portal, Plone4Artists will enable Plone to extract the metadata from those portals, and also to embed the appropriate video player. Plone4Artists also offers standard specialized views for the folders hosting our video objects, and adds Plone video-feed capabilities, as well as capabilities for user ratings, comments, and tagging on videos.

If you want to see all this in action in a real case, just visit http://plone.tv, a Plone4Artists-based Plone portal where you can enjoy both a multimedia-specialized portal and some good videos and audio from the Plone community. Of course, Plone4Artists provides for audio files the same functionality it provides for videos, as well as specific functionalities for content managers, such as a massive file uploader.

A major alternative to Plone4Artists (though built on Plone4Artists roots) is the Plumi project (http://plumi.org). Plumi is supported by the EngageMedia Collective to power the EngageMedia site (http://engagemedia.org), a video-sharing site that focuses on social justice and environmental issues. We won't go into details on the differences between Plone4Artists and Plumi here, but note that Plone4Artists is a bit closer to "pure technology," with all its stand-alone and reusable modules, while Plumi is a bit more use case–specific, since its development is driven by the needs of the EngageMedia portal.

You've received a good introduction to multimedia management with Plone, but you still need to face the issues of handling big files and long-running requests. Clearly, you will have many big files to manage in your multimedia portal, as well as requests that could take more time to process than typical Zope/Plone requests.

To get a deeper understanding of how to correctly deploy a production Plone instance in general, we invite you to look over Chapter 11 again, and also pay particular attention to the following section in this chapter, "Handling Many Large Objects with Plone."

As for the issue of long-running requests, in our multimedia scenario we could get long-running requests both during management activities, such as massive file uploads, and in normal usage, as when serving some really big file. To solve these problems, you need to understand your specific use case and go for some kind of clustering techniques mixed with application-side care and deployment configuration tricks.

For instance, if just a few users are enabled to upload content, it could be smart to offer a dedicated virtual host exclusively for them, and to keep them on an exclusive ZEO client (see Chapter 11 for a deeper look into this topic). On the other hand, if we need to build a reliable streaming portal, it could be essential to implement this feature in such a way that Plone doesn't do the streaming directly. For example, we could implement a more specialized and "static" streaming service using the Tramline technology (www.infrae.com/products/tramline), which bypasses files upload and download issues, delegating them to a specific Apache module in a very clever way.

Clearly, those are not the only technical problems to be aware of when dealing with multimedia portals. For instance, we could mention server-side file-processing requirements to obtain conversions and the like, but that is well outside of the scope of this book.

Handling Many Large Objects with Plone

Handling many large objects is a low-level problem, but Plone has been working out a solution at the application level for years. Zope empowers Plone in many ways, but, until recently, was missing an important feature: BLOB (Binary Large Object) management. In the most common cases, as for the standard Plone 3 file content type, the actual binary file is stored as an attribute on the file object, and is thus duplicated every time the object is touched, even if the binary file is not involved. This behavior stresses the default ZODB FileStorage, which tends to increase its Data.fs file size rapidly; as well, it raises the amount of resources needed to run a Plone instance. In fact, the ZODB loads entire objects in RAM when it thinks they are needed, binary files included, even if they're not going to be used.

That is why, especially for binary file–centric Plone portals (such as multimedia or documental services), it is important to adopt a specific BLOB strategy to store all the binary files we will manage directly on the file system. As it is a very common case, (despite not being a Zope priority until recently), many alternatives have been proposed to overcome this problem. Some of them are provided by specific content types, like the famous PloneExFile, which acts at the application level to separate the file object from the actual binary file. However, this approach is a bit obsolete nowadays. Thanks to Archetypes' storage concept, we can specify which type of storage we prefer per-field, independently from the ZODB, which normally continues to store the object itself. In the "Writing a Custom Content Type" section in Chapter 9, you have seen in detail that Archetypes transforms a field's schema into a Plone portal type. You can specify what kind of storage Archetypes will use for each field, and that is what we are heading toward.

When it comes to binary file fields, we can choose FileSystemStorage (http://plone.org/products/filesystemstorage), supported by Ingeniweb, as a well-known solution to the problem.

FileSystemStorage (FSS), and its eggified version, iw.fss (http://pypi.python.org/pypi/iw.fss), are quite simple to use and configure. They're useful for creating a per-site file system repository where binary files are stored according to one of four provided strategies. In addition, FSS comes with full RDF metadata support and a series of goodies, including a script to rebuild a pure file system version of the repository if needed.

FSS is a good solution, but it comes with a few important caveats: You have to keep in mind that FSS stores files on the file system assuming that you will not access them using the file system directly. In fact, if you do this, you could mess up FSS quite easily—for example, what if FSS needs to delete a file while you have it opened in your editor? You should expect some kind of failure. Furthermore, it solves our problem only for Archetypes-based content, which is not a general solution. Finally, it solves a low-level problem at the application level, which is not the most elegant and versatile solution.

But why are we stressing FSS's weakness instead of its good features? Well, because a proper low-level solution is available, and it is known as BLOB support for ZODB. Of course, if we adopt BLOB support for ZODB, the application-level flexibility we gain with FSS is lost; in fact, its files repository is a much more cryptic beast than the one implemented by FSS—quite obscure from a Plone point of view. Nonetheless, using BLOB support for ZODB, we gain a clearer and more efficient solution: the ZODB is Zope's standard storage method, and it precludes us from needing to solve our problem at the application level (unless we want to duplicate our efforts to guarantee reliability and robustness). Of course, we won't have direct access to our files, but that is typical of any relational DBMS, and should not be so hard to accept, unless you prefer the FSS solution.

BLOB support has been at the core of ZODB since version 3.8.0, and the plone.app.blob package, which fits ZODB BLOBs into Plone, is almost in a stable release. plone.app.blob provides a replacement for ATFile, changing the standard ATFile's file field with a BLOB support–enabled one. As well, plone.app.imaging provides a replacement for the standard ATImage's image field, covering the basic standard content types with binary fields in Plone. Plone's next releases will probably propose a standard way of tackling the problem of adopting ZODB BLOB support. As for your projects, have your choice, and go down that road as needed.

Now, let's approach our second issue for this section: what to do when your Plone site hosts many objects. First of all, if you need to host thousands of files in a single folder in Plone 3 or earlier, remember to use a Large Plone Folder and not a standard one, at least until the current Plone developers' effort to implement a unique kind of folder with the ability to manage many objects by itself is finished. You can enable the creation of Large Plone Folders just by visiting the Types configlet page in the Plone control panel, choosing Large Plone Folder, and selecting the "implicitly addable" check box. Large Plone Folders are important when you just need to access real objects; in the cases of listing and searching objects, you can use a catalog query instead. So, now let's focus on the portal_catalog tool and its features.

A primary notion you need to understand is that the catalogs store their indexes and information in the ZODB using a special kind of object called a brain (we introduced this concept in Chapter 11). However, the standard Zope configuration is based on a single ZODB database, and it is not possible to tune the ZODB cache to keep all the brains you need separate from all the other kinds of objects in the ZODB cache.

The trick here is to configure a second ZODB database, where we store only the portal_catalog tool, for which we will safely set an extremely high number of objects in cache. This works great for brains, since brains are tiny objects compared to standard Plone content types. Setting up a separate ZODB database for the portal_catalog tool makes it so that after the first few requests, all the brains we need are calculated and cached in RAM, making Plone's catalog queries much quicker and more efficient. (This technique was examined in detail in Chapter 11.)

The last tool we would like to introduce is ContentMirror, which lets us approach the many-files performance issue from a different point of view, and could be useful in some specific cases. Imagine you need to continue to use Plone for your content management, but you also need to publish the same content to a much larger audience and with way less flexibility. In this case, you would just need to let the readers access published and updated content, perhaps with simple access control, like a token on the request. This is quite typical in many cases where Plone is used to manage news sites, or big database sites with many anonymous visitors asking for information but never contributing to the content.

In this and similar cases, you could think about building a simple and efficient publishing application, able to consume the Plone content database. Not that easy, you think? Well, not that hard, either, if you adopt ContentMirror, which we mentioned at the end of Chapter 10. Content-Mirror synchronously pushes Plone content and its metadata into a relational database, so that any other specialized content publication application can safely publish it as needed, and always keep it up to date.

Of course, a lot of other possible strategies could be chosen, depending on the specific use case, but that is part of the art of building powerful Plone sites. As always, you will need to balance Plone and application-centric methods with proper service configuration as well as possible.

Integration of External Applications and Single-Sign-On

All IT managers know that the curse of IT infrastructure consists of an uncontrolled proliferation of applications: different interfaces, different search engines, different ways of managing data, and different types of authentication. If you are lucky enough to have your company mission, requirements, and means let you do so, you can move all your applications into Plone and solve all your problems.

This is wonderful because it does not matter if the sentence you read the last month was in a commercial offer, in a PDF document you received in an e-mail, in the documentation of a project, in the description of a book in your company library, in a post on the company forum, or in the blog of the CIO. If it's in Plone, you will find it. You must remember that Plone does content management, which extends beyond web pages, and all the contexts we listed in the previous example are content-oriented. Having the same interface for creating, editing, and managing content is a great advantage. This will save time when you have to learn how to use new features and avoid mistakes due to lack of knowledge of the less-used ones.

One of the most appreciated strong points of a fully integrated enterprise system is unified authentication and authorization. For example, you no longer have to deal with dozens of passwords that you risk forgetting or have to write down. Instead, you're provided with a unique tool that lets you decide if a user or a group can access a specific resource.

However, integrating different applications in a single platform is not always possible. Sometimes applications are complex, not open source, bound to a specific operating system, not web-oriented, and so on. In these cases, you do not have to give up—Plone can still be a collector of resources. You have already seen in Chapter 10 how you can index a file system with Reflecto; in the same way, you can index remote file servers. This makes all your company documents searchable by Plone. You can even carry over the same privileges from Reflecto so that site members can search only what they have permissions to see.

However, in most companies, information isn't stored only in files, but also in a database. Fortunately, it does not matter what the front-end application is—Plone can access any common database (at least any database supported by the Python language).

Plone can access databases directly with traditional SQL queries. We can show information as Plone content, or simply make the databases searchable by the Plone search engine (see Figure 12-1 for an example of this kind of structure).

Figure 12-1. The flexibility of the Plone search engine allows you to search not only through the site content, but also through external data sources, like databases and servers.

To go further with the integration of our external applications, we will describe how to share authentication among them; to do so, we will divide our task into two stages. The former is to use the same authentication parameters for all the applications. This is easy for Plone because it can easily use various back ends for authentication (see Chapter 8).

The latter stage in integrating authentication is to provide a single-sign-on (SSO) among your applications. This can be achieved using an external SSO server and a corresponding PAS plug-in; on Plone.org you can find many of them. But you can also use Plone directly as an SSO server. This can be very effective when you do not have many applications and you can modify their source code. Using XML-RPC, applications can ask Plone if a user is valid, and they can let Plone manage the whole login process and even share users' data (see Figure 12-2 for an example of this kind of integration system). This can be an important step toward full Plone integration.

Figure 12-2. Plone can take care of user authentication even for queries that come from other platforms, regardless of the user's source.

Custom Member Profiles

Sometimes the users of a web site consist of more than a username and a password. Plone includes some extra fields for users, the most famous of which are the full name and e-mail fields. But if these are not enough, you are free to add more fields according to your requirements.

As usual, the Plone philosophy is to follow modularity, so we do not have to reinvent the wheel. We can rely on the Archetypes framework, which lets us create content with all the fields we need, and on the pluggable authentication service (PAS), which lets us choose where to get login data (for more details, see Chapter 8).

To exploit these features, you have to use the Plone add-on products Membrane and Remember. Membrane (http://plone.org/products/membrane) is a set of PAS plug-ins that allow for user-related behavior and data (authentication, properties, roles, groups, etc.) to be obtained from content within a Plone site. In other words, it allows you to support members as content types in Plone. Remember (http://plone.org/products/remember), as the project description says, "provides a set of plug-ins that let developers use content objects to provide information about user properties, groups, and roles. Remember builds on this, using Membrane to fully reconstruct the default Plone member implementation with each portal member represented by a regular piece of Archetypes-based Plone content."

With these two add-ons, you will be able to manage users just as you do normal content. For example, you can build a structure that will represent your organization using folders as groups, create and delete users as you do with content, change their workflow status to disable their login, or require the approval of a reviewer before self-registered users become valid. It is also possible to give some users the rights to create other users in specific folders, using the usual sharing interface. If the folder is removed, the users are removed too. This can be incredibly useful for local workgroups because you can avoid having to ask the site administrator to create users.

Using Archetypes objects for your users lets you create complex relationships among users. For example, you can specify the boss for a group or an arbitrary set of users, and then use this information to manage permissions in workflows (e.g., the reviewer of content may be the boss of the author).

For simple cases, Plone ships with a tool known as portal_memberdata, which lets you add new properties for users without installing any add-ons. However, using Archetypes gives us many more advanced possibilities, and it is suggested for complex cases.

Community Portals and Social Networks

Plone can also be a good platform for creating large community portals and social networks. Plone itself supports autoregistration of new members, as you have seen in Chapters 3 and 4, which is great when you're working with social networks. Registered and confirmed users can use a dashboard, they can have a personal blog with optional moderated commenting, and they can use many other features. For example, each user can create an image gallery, tagging photos in certain areas with names and notes; identify community members; create an internal inbox message service from users; implement internal chat; and so on.

What about community portals? A great example of their use can be seen with Plone.org itself. With a simple out-of-the-box Plone site, you can quickly create a community portal that provides community members and your visitors with

• Updated news and important announcements about the main projects of the community
• Events and appointments related to the main projects of the community
• Training courses
• The latest software releases
• Documentation
• Support

You can of course take advantage of the powerful internal search engine (e.g., restricting search to a certain area, or performing an advanced search).

It is the big community of users itself that can create and update the content on your community site—all you have to do with your Plone site is enable the self-registration of users, as described in the "Managing Security Settings" section of Chapter 4. Of course, the entire system will have to be regulated by an appropriate workflow: for example, visitors can register and, when the team that manages the site approves the request, users will have their own account. All the content they will add, such as a news, a training course, a new project, and so on, will be submitted for revision, and the review team will have the power to publish it. Only then will anonymous users see this content. To review how to manage and customize workflows, review Chapter 7 and 8. You'll be able to create new and custom workflow states or transitions in order to meet your specific needs.

If you want to periodically update your users about new products, events, documentation, and so on, you can use the RSS feeds. As we discussed in Chapter 3, in the "Gathering Disparate Elements into Coherent Collections" and "Finding Content in Your Site" sections, Plone by default lets visitors subscribe to a search or a collection, so that they will receive alerts every time new content that matches certain criteria is added, without their having to check on the site. (For even more information on this, see the "RSS Integration into Plone" section of Chapter 10.)

As you have just seen, you can create your own community portal just by configuring a standard Plone site! You already know all the steps you need to perform. Additionally, it's easy to find useful extensions to integrate (e.g., internal chat, forums, or blog support). A good product for integrating online chat in your Plone site is PloneChat (http://plone.org/products/plonechat). To create a discussion board in your Plone site, a good product is Ploneboard (http://plone.org/products/ploneboard). Finally, a survey section can also be a big help for sharing feedback and new ideas; a good product for this purpose is Plone Survey (http://plone.org/products/plone-survey).

Intranets and Document Management Systems

With Plone, we can build well-constructed and flexible intranets with wide user bases. By intranet, we mean a private area to securely share any part of an organization's information. Of course, in practice, intranets can be way more than this. Nowadays, almost all companies use intranets as a collaboration tool—and for them to be as efficient as possible, they have to be based on the enterprise's specific needs.

Thanks to Plone's features and extensions, you cannot only improve content management and internal communication within your intranet by adding various tools and specific workflows, but you can also implement subsidiary services that will be useful to intranet users.

The Plone CMS, as described in the "Setting Up Your Dashboard" section of Chapter 3 and the "Managing Security Settings" section of Chapter 4, provides a personal area—the dashboard—that any user can manage autonomously, setting different portlets that will show updated information any time the user logs in. With the dashboard, the user can configure RSS feeds, choose to view recently modified content, set up shortcuts with links, and so on. Just like with an intranet, you can also enable a personal folder for any user, with particular security settings so that only that member (and administrators) will be able to add and edit content in that folder.

It is easy to create entire areas that can be accessed only by certain groups of users, apply different workflows and workflow policies, and integrate user management with LDAP or relational databases. You can index and search information—even PDF and DOC files—intelligently, and keep track of structured metadata about the content. And many of these features and capabilities are of course integrated into Plone by default.

With regard to internal enterprise communication, you can also create news, events, and alerts easily in Plone. Never forget the importance of social networks: you can create a blog, a forum to enable the sharing of knowledge, a survey section, an internal chat mechanism (see the previous "Community Portals and Social Networks" section). You can even integrate tools for project management, such as a ticketing system.

A very common use case in enterprise communication is the use of a portion of the file system shared through the enterprise network. With the Reflecto product, it is possible to incorporate part of the shared file system into a Plone site, so that each file is treated as Plone content, and the files in the mapped parts of the file system are indexed, searchable, and manageable directly in Plone. Reflecto lets you manage and access files contained in a defined area of the local file system as Plone content, taking advantage of the collaboration tools you enabled, and all the usual content management policies you are used to working with in Plone. Content can be added through the Plone interface or from the file system.

Enterprise intranets can benefit a lot from Plone. Plone allows you to, of course, access databases in read mode, even if they've been written by other applications. But you can also integrate them into your intranet so that you can implement search features and make queries on data that comes from other systems, or integrate and manage data that comes from ERP systems within Plone.

Plone also allows for the capability of sending content as faxes and integrating messaging features to send alerts via SMS messages to certain groups of users.

We could go on with many other examples and specific use cases, but the point is that Plone is not just a CMS! It offers the chance to meet almost any enterprise need regarding internal communication and project management, thanks to its default features and extensions.

Plone: Faster Than Light

It is a common belief that CMSs are slow. This might be true for other CMSs, but not Plone. Thanks to its architecture, Zope/Plone can have very good performance in both speed and load. With the right tuning and tools, it is possible to build systems that satisfy every need. The first step is to understand what you are looking for. In this section, our goal is not to analyze any particular solution, but rather to let you understand what you can tweak to improve the performance of your applications. So, we will use a general-purpose enterprise architecture.

In this general example, we'll assume an Apache (or nginx) web server as a front end to our web application (see the "Plone Behind a Web Server" section in Chapter 11), which allows us to do virtual hosting and HTTP and HTTPS request management, if required. The web server will act as a reverse proxy, sending users' requests to two different back ends. If the request is coming from an anonymous user, it is sent toward a Squid proxy server, which is followed by a load balancer. Logged-in requests are instead sent directly to the load balancer.

The presence of Squid permits us to provide dynamically generated pages at the same speed as static ones. This is primarily very useful for images and files (e.g., CSS and JavaScript). However, normal Plone content can benefit from caching as well, particularly with the use of the CacheFu add-on product, through which you'll be able to manage the persistence and validity of pages and avoid providing expired content.

When installed in Plone, CacheFu provides a configuration area in the Plone control panel (we discussed CacheFu at length in Chapter 11—chiefly in the "Caching Proxies and Your Plone Site" section). Through this area, it is possible to configure many parameters to have the right caching for each need; the more expert you are about the HTTP protocol, the more advantage you will get with the right tuning. But even if you do not know anything about it, you can improve your site performance simply by installing this product with its default options.

Note that a proxy cache is most effective for anonymous users, because content besides CSS and JavaScript that can be cached in the browser is usually user-specific. Proxy caches are usually avoided for logged-in users.

The next step involves the load balancer: its job is to spread requests among ZEO clients. An open source solution for load balancing is Pound, as mentioned in Chapter 11. Pound acts as a reverse proxy, forwarding requests according to the performance of the recipients, which are the core of the system: ZEO clients. They do the hard job. All the computation is done by them, so they are very important for the performance of our applications. But the good news is that you can have all the ZEO clients you want, spreading the load among different machines (at least as many as you can afford!). You can easily clone a ZEO client, add a new one in the balancer pool, and improve the capacity of your system.

Behind ZEO clients, there are one or more ZEO servers that keep application data. Both servers and clients can be spread out geographically (e.g., you could have a ZEO server in one city and the ZEO clients in others). Depending on your application's requirements, the various ZEO servers can store different parts of the application's data for structural and also performance reasons. Obviously, all this makes sense only in particular cases; in most cases, Plone will satisfy your needs out of the box.

At this point, you have seen how to organize your system to increase the speed and load it can bear, but you can also work on the application side. By default, Zope provides two ways to enhance the application's speed: caching the results of computations on the server, and modifying the HTTP response headers in order to manage persistence of web pages in the browser or in the proxy.

Summary

We have come to the end of our journey. You should now be able to use Plone, configure it, integrate it with other systems, and develop web applications. Throughout this last chapter, we've given you some real reasons why you should choose to learn the functions of this powerful CMS.

We went through many common use cases, such as building an e-commerce site, a community portal, a social network, and an enterprise intranet. We covered how to manage big files, how to integrate automatic handling of documents and images, multimedia management, custom member profiles, and SSO.

Of course, we could have chosen other examples; but it is time to take your bag of skills and start to build the most important thing that will allow you to use Plone: a wealth of experience. We are sure you will find out that Plone is exactly what you were looking for!