Plone 3 Intranets

As we already know, CMS stands for Content Management System, but this definition is very broad and is applied to a large set of solutions. Many authors tend to split them in several categories, the most important are: Web or Portal Management Systems (WMS) and Enterprise Management Systems (EMS).

Drupal, Joomla, Plone, dotNetNuke, to mention a few of them are WMS. There are others targeted to specific use cases of content production, such as Wordpress or Zine, which are aimed exclusively at blog publishing. Although it is common to call them WMS, there are some authors that treat them as a special case.

WMS software is a web application for creating and managing large, dynamic collections of web material (HTML documents and their associated resources). Usually they provide authoring (and other) tools and rich user interfaces designed to allow users with little or no knowledge of programming or markup languages to create and manage content with relative ease of use. A database is used to store content, metadata, and in some cases other types of artifacts as code or templates. Usually, a presentation layer displays the content based on a set of templates.

One of the most distinctive features of the WMS market is the way the users manage content. In fact, there are two approaches:

In the backend approach, the system makes available to the user a special interface for managing the content resources, as well as administering the system. In the in-place editing, the user can manage the object directly through the frontend user interface, using special widgets the system provides for that purpose.

Another important feature is how we store and choose to show content on our site. Most CMS rely on taxonomy, tagging each document with an ID, which is used to specify where we want to position it on our site. This is the approach chosen by Drupal, Joomla, and so on. They also use the concept of asset library, a place to put resources for a later use on our site.

There are a lot of WMS that are backend driven, and although some of them allow some kind of in-place editing, the experience is not always as pleasant as we would desire. Some of them rely on taxonomy to build the site structure. Taxonomy is the practice of classifying objects according to natural relationships. This method fits into the brains of technical users, but it's not easy to understand for non-technical users due to the complexity of the concept and, often, due to a poor and non-usable interface.

We can find these features and more in any modern WMS. However, what are the differences between WMS and EMS? The boundaries between WMS and EMS are becoming more blurred in recent times. Enterprise Management Systems are targeted to capture, manage, store, preserve, and deliver large amounts of documents, and treat them as individual entities. Often these documents are stored in XML, which provides easy integration and interoperability with other systems. They are focused on the management of the life cycle of a document and they often integrate powerful business process management (BPM) tools. They can also provide archiving and Public Key Infrastructure integration. To name a few: EMC|Documentum, FileNet, or OpenText.

Although we can find some of these features in a WMS, or we could just implement them, we have to keep our needs in mind. We have to decide what kind of tool is the most suitable for our requirements and meets our needs. Not all needs end with the choice of a general WMS, for example, if we need a simple website with the brochure of our business, maybe we will choose a WMS like Joomla or Drupal. If our organization is related to the government or it's a big enterprise where we need integrated document management, with the highest audit and control requirements, and we are not interested in publishing our site, then we probably need an EMS.

From a broad point of view, an intranet is an access-controlled site along with optional external publishing capabilities, which has the following key features:

Plone excels in all of them. Let me show you how.

For non-technical users, it is essential to provide the simplest and a highly usable user interface, relying on concepts that they already know and they will be able to easily extrapolate to our use case. Here is where in-place editing and a tree-based hierarchy come into play.

A tree-based hierarchy is a repeating concept every user has to learn when dealing with computers because of the structure of file systems. It is easy for users to apply this concept when it comes to managing content. Plone uses a tree-based hierarchy for organizing its content and transparently storing it as objects, provided by the ZODB, the Zope's object oriented database. From the user's point of view every Plone site has a root folder, which is a real physical place where they could place content, and eventually folders that would be physical containers of more content. First-level folders would become the website's sections. In my experience, users are very confident in that scenario, and they learn the concept almost immediately. They can even do the same basic operations over content such as cut, copy, and paste as they used to do with files in a file system environment.

Another key aspect people can expect from an intranet is security. I'm not talking about restricting access to our site to authenticated users only. It's about being able to define authorization over content objects by specifying a complex permission structure on them too. Plone provides a granular and highly configurable security engine. Permissions are defined at the object level, assigning specific permissions to every single object. The Plone pluggable authentication service (Plone PAS) takes care of the connection to the most common authentication methods (Local, Active Directory, NTLM, LDAP, SQL, Novell, and so on) and its pluggable architecture can be extended to support others.

Enabling workgroups and collaboration is a must in an intranet. We have a constant need to share our daily work and we often need a centralized place to do so. A few years ago, the initial purpose of intranets was to be mere information containers. Today, we are constantly asked to improve their capabilities and we are continuously making them more powerful. Forums, blogs, form and survey generators, contact management, resource bookings, travel expenses; all of these could be nice features to add to our intranet. Intranets must provide us with a way to make our daily work more easy and reusable. Plone has a long list of add-ons that can help us in this matter. In short, probably the most used topic in IT in the beginning of the 21st century—Web 2.0!

Productivity is not a joke for any enterprise or organization. We are living in a world that demands the highest standards. We must work efficiently and achieve the highest quality results by spending the least amount of money possible. Having the right tools to accomplish this is not an option, but a must. Again, there are a lot of add-on products that provide these kind of tools. Many of the applications that we mentioned earlier in this chapter could help us achieve that.

A very useful feature that is able to define the life cycle of content is called workflow. Workflow is composed of states and the transitions between them. The states define a set of permissions and visibility of the content, and the transitions define the actions to be taken when content's state change is triggered. Plone provides a highly customizable workflow engine, and the most common ready-to-use OOTB workflows. The right use of workflows is the key to a successful intranet.

As we have seen, nowadays, there are a lot of successful WMS applications and the most popular ones are PHP based. Joomla and Drupal are good examples; we could even mention some extremely successful websites such as Facebook, which are PHP based. The popularity of PHP is not a surprise; good documentation, a shallow learning curve, its similarities in terms of keywords and language syntax with other popular languages such as C, its web oriented architecture, and a long career in the IT world are its credentials.

The first thing we notice about Plone is that it is, in fact, a Zope application. To be more exact, it's a Zope product. And because of that, against all odds, it's Python based.

I'm a Python lover, and this romance has its reasons. Having reached this point, I could just begin another little war between PHP and Python, but I won't. There are a lot of discussion boards on the Internet about this subject, and we can find them easily. Instead of opening Pandora's box, I will talk about the excellences of Python, and why it excels in doing its job.

Python is a dynamic object-oriented programming language that can be used for all kinds of software development. Guido van Rossum, former employee of Zope Corporation and now working for Google, created it in the early 1990s at Stichting Mathematisch Centrum in the Netherlands. As we may already know, Google has made a strong bet on Python, and is using it in Google Apps Engine and presumably in the core of its most popular services.

It offers integration with other softwares and tools, and comes with extensive standard libraries. It features a very intuitive and easy syntax and can be learned in few days. Following are some of its key features:

Yet another surprise? Yep, I will tell you just one thing: you can forget all you know about relational databases, SQL query languages, tables, fields, and stuff like that. Let me introduce you to the mighty ZODB! If you don't know anything about it, don't worry.

The ZODB is an object-oriented database for storing Python objects transparently and persistently. It is included as part of Zope, but can also be used independently out of Zope. The reason for not using a relational database management system (RDBMS) is easy to understand. It is more natural for a Content Management System to store data in objects than to rely on an abstraction layer that converts the document object we are storing to fields in a table (or fields across several tables), and again when we retrieve the data from the object. In all aspects, it is easier to store the object directly and transparently in the database as an object.

Plone stores the site content, components, templates, and code needed in the ZODB. The content is saved in the database following a tree-based hierarchal structure from the root of the Plone site. Every item of content is an object, and the associated metadata (title, description, body, and so on) are its attributes. As we said before, for some applications like CMS, it is more efficient to store content in this more natural way, as the type of entities we are managing is most of the time structured hierarchically. ZODB users don't have to know where and how all this is stored, because the entire persistence layer is transparent to them.

Following are its main features:

On Zope, every transaction is stored and is not written in the database until it is committed. This means that if an operation fails while it is running, the database remains unchanged, as no data is committed to the database until the end of the operation.

As every transaction is stored, we can see the history of all operations for a container. We can undo the transaction and revert to the state before that transaction was made. So, if something goes wrong, or if someone deletes a folder by mistake we can simply recover it by undoing the transaction.

Believe me, these two features have protected us from a lot of nasty headaches.

Now it's time to introduce you to the Plone community. You will find that it is an exquisite cocktail and its recipe follows like this: lot of highly-talented people immersed in an exciting and continuously challenging project, along with some crazy geeks and high level third-party add-ons contributors, two spoons of wisdom provided by the Plone Foundation, and finally shaken, not stirred, with a high amount of friendship.

This community has the key to all our questions about Plone. There are a lot of people eager to help those who ask for it. We can reach them via mailing lists or chat room (visit http://plone.org/support). It is also the entry point to discuss every aspect of Plone, its design, features, and future. You may take a look at what is said in the planet of blogs (http://planet.plone.org), what is being planned for future releases of Plone, what is happening in the community (http://plone.org/news and http://plone.org/events), and you can be a part of it.

There are lots of ways to support and promote the community; one of them is attending periodical events such as conference, symposia, and sprints. There are many others, such as organizing local meetings about Plone; just a little digging is needed to find out if there's one in our city, and if there is none, then create one!

The Plone Conference is the most important event inside the Plone world. It is held every year since 2003, and it is organized by the local community of a designated city. Attending a Plone Conference is the best chance one has to meet the Plone community in pure state. Having firsthand experience in how it is designed, how it is made, how it works, and the possibility to take part in the development of new Plone features is invaluable.

One of the key points behind Plone being one of the most active open source projects is not any accident—it's the Plone community without any doubt.

There was a time when public websites, extranets, and intranets were separated by well-known and defined borders. These borders were defined by file system permissions set at the OS level, and were statically defined and not accessible by users.

Nowadays, the difference between them in most cases is a thin line, often defined by object properties (such as a state or user security permissions) that determines the visibility and the access rights for each object of our site. As we said earlier, Plone allows us to set up a property called "state" at object level. This state will have a set of permissions associated with it that will define the access to the object itself. These permissions are part of a bigger set of security-related properties that allows us to manage object security more accurately and helps us to have high granular security management.

As we can determine the visibility of each object, we can have public access objects living in the same folder, along with others with restricted access rights.

This leads us to the paradox of having a public site that could easily have an intranet section protected with access rights, or a big intranet where it is permitted to publish certain content or expose public sections to anonymous users.

Changing states of content in the Plone UI is only two clicks away. A state is the main entity of a workflow and, among other things, it defines the user permissions of the object. Each content type can participate in a workflow (or none if we don't want to) and Plone provides us with a way to define and manage them. Plone is shipped out-of-the-box with some common use workflows, but we can define and manage them to fit our needs.

In this chapter, we have learned all the basic concepts of Plone, along with its features, a few of which were actually surprising for newcomers. We also introduced the Plone community and why Plone is a good option to build out intranet using Plone.

In the next chapter, we will cover the installation and first steps with Plone.