A website is composed of Zope objects instead of files, as is usual with most other web server systems. The advantages of using objects instead of files are:

Combining behavior and data in a more natural way than plain text files.
Encourage the use of standard components that address a particular part of forming a web application, allowing flexibility and decomposition.
Enable automatic processes of information management.
The most characteristic feature of Zope is based on object-oriented data, called Object Database ZODB or Zope. This database stores objects arranged in a system similar to a file system, but each object has properties, methods, or turn contain other objects. This approach is very different from the standard relational database.

Plone is a Content Management System or CMS for its acronym in English (Content Management System), based on Zope and programmed in Python. In a development based on open source. Can be used as intranet or extranet server, a document publishing system and groupware tool for collaboration between distant entities.

The Plone project begun in 1999 by Alan Runyan, Alexander Limi and Vidar Anderson. It quickly became one of the popular and powerful Content Management Systems Open Source. In 2004 Plone Foundation was established to protect and promote the use of Plone.

Plone is released under the GNU (General Public License). It is built on the open source application server Zope and the accompanying Zope Content Management Framework, which has thousands of developers around the world.

• static pages hosting
• Enable load balancing
• Encryption (SSL, TLS) without configuring the server Zope
• Authenticate (password, TLS client certificates, etc.)
• assign authorize (user / URL access)
• Abstract address space (eg, CGI, PHP, and Zope mixed external resources under different URL, URL, description etc.)

For example, a Zope resource (eg http://localhost:8080/SSL-Blog) under one domain name (eg http://www.ssl-blog.de) via http will be made available and localhost to another (eg: 8080 / manage) will be displayed under a secure SSL URL. Consequently the necessary condition for dynamic conversion of references is the “Virtual Host Monster (VHM) in Zope, and either or libproxy mod_rewrite in the Apache configuration. “Libproxy” is understood to configure, so it is used in this example.

Simplified directs incoming requests to said libproxy and the VHM change addresses in outgoing documents using the calling URL.
In the Apache configuration (in Zope has only one End to the root are added, additional configuration deleted) sees it like this:

Server Name www.ssl-blog.de
ProxyPass / http://localhost:8080/VirtualHostBase/http/www.ssl-blog.de:80/SSL-Blog/VirtualHostRoot/
ProxyPassReverse / http://localhost:8080/VirtualHostBase/http/www.ssl-blog.de:80/SSL-Blog/VirtualHostRoot/
The URL “/” is implemented by the Apache on the server localhost port 8080 Under the address “/ VirtualHostBase /” is called and the VHM is instead of “localhost: 8080″ the URL “http / www.ssl-blog.de: 80″ (“http /” and “80″ stands for http on port 80). The directory “SSL Blog” on the Zope server is handled by the End because of the “VirtualHostRoot” as the root directory of the virtual server.

Just as a resource can be any Zope in the address space of an existing domain Zoom:
[...]
ProxyPass / zope http://localhost:8080/VirtualHostBase/https/www.irgendwo.local:443/VirtualHostRoot/_vh_zope
ProxyPassReverse / zope http://localhost:8080/VirtualHostBase/https/www.irgendwo.local:443/Virtual_Host_Root/_vh_zope
[...]
This is the “https: / / www.irgendwo.local / zope” to the Zope server “http://localhost:8080″ prefix.
“VirtualHostBase” calls the VHM and “https / www.irgendwo.local: 443″ are protocol address and port of the web server. “Virtual_Host_Root” sets the path down on the Zope server (“/”) and _vh_zope “ensures that the VHM to the server name to the path” / zope “append (” https: / / www.irgendwo.local:443/ zope “).

Zope is a web application server open source written in python . This development framework for web applications has given a base object (NBA) that develops directly from a web browser. Types of simple objects such as documents, images, page templates, are available to users to be created and managed via the Internet.

The architecture of Zope integrates a powerful management rights and workflow (document flow) on your objects. It includes its own HTTP, FTP, WebDAV, but can also be used with Apache or other web servers.

You can create with the framework of fully dynamic web applications and very powerful. I advise all developers who want to be an environment that is very powerful and a bit of time before had. Its default? The learning curve of technology that can be long!

Queries are interpreted by the ZPublisher. From there everything becomes an object, starting first with the request. Zope’s approach is radically different: a LAMP architecture where the trail system files for the PHP script to run, ZPublisher through a hierarchy of objects contained in an object database. The object selected by this operation inherits the context of the application, that is to say, attributes of objects of that container. Things can go wrong when we try to apply this mechanism, because there are subtleties that we can report back with this document (note the headaches!).

The ZODB (Z Object DataBase) is the database that contains the object hierarchy (more commonly called FileSystem Object, or SFO) to the instance of Zope. The objects of a site is being persisted and serialized in advance (a mechanism known as pickling in Python world). The objects can be containers, images, views, methods, objects, etc..

The classes we can instantiate the object hierarchy are organized in “Products” or zClass Zope (the latter fell into disuse). This can range from a “adapter” for a SQL database to an application as complete CMS Plone. Many products have come to be integrated into Zope 2, which gave him a hand “monolithic”. However, thanks to the product CMF (Content Management Framework), a set of components that represent the different bricks needed to develop a CMS that was Plone reach the point where it is (an open source CMS advanced).

Long ago, Zope 2 products had a reputation for being difficult (or, at least tedious) to write. This is one reason why the development of Zope 3 has occurred. This is not an evolution of Zope 2 because the architecture has changed fundamentally: in fact, Zope 3 is based on a component architecture based on the use of interfaces and “adapters” (which administer the Communication between components). In addition, these components can be used independently of each other (zope.interfaces be used in other libraries including Python twisted) and their development is much more enjoyable.

Skip a Zope 2 to Zope 3 components requires a complete rewrite. In order to facilitate the migration to this new architecture, called a Zope 2 Five was built to allow the use of components of Zope 3 in Zope 2. Thus, all the new features of Plone (since version 3) are now developed on Zope 3. However, the basis of this application will remain on the Zope 2 for a while, because it affects a lot of code and there is no necessary advantage to rewrite everything.

Firstly, J2EE has been supported by the largest dinosaurs of the computer such as IBM, Oracle and Sun Microsystems course. The training provided by these dinosaurs, the success of open source projects in the professional J2EE (JBoss, among others) and the business need of information systems increasingly complex did the rest.

Second, the peculiarities of the technology and the adaptation time required have certainly deterred some makers. We shall see later that it is absurd to actually be repelled by Zope rather than by the EJB2.1 specification or even Struts 1.x.

Last but not least Zope is clearly focused on content management (ECM, CMS, …) while J2EE is active in many other areas. Consider the general architecture of Zope to understand its strengths in content management.

I bet APP support would be welcomed by the Quills team. How does this affect WebDAV? APP lacks some of the frills of WebDAV. On the other hand, it’s easier to implement. It’s been a tough time getting interoperable WebDAV into Plone core. Maybe APP, with its simplicity, is a good alternative? APP is also, along with Atom, the basis of GData. Thus, it makes sense to implement APP support first and then build on it for GData (another source of scope negotiation for the SoC). You Might Look at amplee or FlatAtomPub for Inspiration.

I would like to propose a different task. Instead of reinventing the well, we should build upon entransit. The goal for entransit is * not * spit out PHP, but structured metadata. Right at this moment we are looking at using JSON to represent the metadata on the filesystem. Then, on top of that a good task would be to consume this JSON into a database and (additionally) have a PHP (or Java, or ASP.NET) app that consumes the data either from raw JSON or from a database. I would volunteer for mentoring this task.

As long as the data’s in JSON, why not just a simple backend and a javascript engine to format? Something like using gNius ? OK, for performance reasons, this * may * be a horrible idea. But ti sounds like a lot of fun!

This meeting will feature a special preview of Plone 4, and networking opportunities for businesses & individuals working in or wanting to join the Plone community.

Everyone is welcome. This is not a sales pitch, just a chance to learn and be involved. Help us build a group that meets your needs and promotes Plone in our area.