February 17, 2019

The Zope Application Server Revisited - page 3

Introducing Zope

  • January 7, 2000
  • By Kevin Reichard

One area where Zope does compare unfavorably with more established application servers is in its lack of advanced development tools. With every other major application server you have an accompanying "studio" product for offline application development. Typically these development tools sport a graphical interface and stand alone as application-development environments. (Allaire's Cold Fusion really began life as a development environment, not as an application server.) Typically these development environments also come with several applications, both to show how applications are developed and also to create new applications.

Seeing a need for a studio environment, Digital Creations and Mozilla (the open-source-development group that's developing future versions of Netscape Navigator) have formed an agreement to develop management tools for Zope. You can read more about the Zope/Mozilla agreement here.

The development environment associated with Zope, a Web-based interface to a Zope server, works surprisingly well, given its limited nature. I used the Web interface to create some simple applications, relying heavily on the documentation to guide me through the process. The one drawback is that Zope doesn't ship with many prebuilt apps. While you can easily grab some from the Zope Web site that were developed and configured by volunteers, they don't substitute for the power of an application-development suite. Anyone not familiar with Python will have a difficult time developing for Zope (as I did, even though I've developed applications on multiple application servers).

And you'll need to code by hand, basically. Zope features DTML, the Document Template Markup Language. (Sadly, there's no way to work with Zope without using DTML. Contrast this with the upcoming release of Cold Fusion 4.5, which adds Java capabilities and decreases the importance of CFML.) The DTML tags are placed directly within your HTML code. These tags are basically used to include variables.

To generate content, you'll need to work with a Zope-supplied Web interface, rather than working with a third-party editor. Quite honestly, it took me a good while to develop an application under Zope, mostly because of my lack of familiarity with both Zope and Python. However, once I spent some time poring over the documentation, and heeding my son's exhortation to "try, try again," I managed to create a small groupware application that stored a rather inconsequential set of data in an SQL database. Basically, the framework for creating applications involves Z Classes, which are objects containing their own methods and properties that can be implemented anywhere within a ZORB hierarchy. To create a Z Class, you can use the Web-based Zope development interface without resorting to a programming language like C++. The lesson: you're not going to be able to jump right in and develop applications using Zope, but once you've developed some, you'll find that the same object-oriented mechanisms and procedures can be used time after time.

Part of the problem with Zope, quite honestly, is that it doesn't play by the rules set forth by the rest of the application-server field. Start hanging around application-server vendors and you'll quickly find that there's a list of mandatory features that represent checklist items when selling into the enterprise. The application-server heavyweights make it quite clear that they're in the business of connecting databases in the enterprise and enabling e-commerce solutions for major players.

But as the open-source world is more (for the lack of a better word) idealistic and bent on presenting things in a unique light, you see Zope repeatedly referred to as an "object publishing system," whatever the heck that means. Structurally, Zope works like most other application servers. The user connects to a Web server via a browser. The server passes requests to an Object Request Broker (ORB) via a publisher. The ORB queries the database, finds the requested data, formats the data in HTML via the Zope-managed templates, and then sends the data to the user.

That, dear readers, is exactly how almost every application server on the market works, give or take a few small twists in the process. However, the devil is certainly in the details, as there's a host of programming languages and object protocols to achieve these goals and ensure that high-level servers can speak to one another even if they come from different servers on different architectures. And it's on the level of details where Zope comes up somewhat short.

Most Popular LinuxPlanet Stories