Summary

VistaSource is a new, wholly-owned subsidiary of Applix, Inc. The firm was formed by spinning off the products and personnel that formerly made up Applix's Linux Division. Software products include the Applixware Office Suite for Linux, the SHELF development environment, and several SHELF components. Web properties include Cosource.com and SmartBeak.

VistaSource needed to get a web site up to coincide with the launch of our firm, and we had less than 7 days to accomplish the task. Rich out-of-the-box functionality combined with a wealth of outstanding add-on products were essential. As an open source friendly firm, Zope was our natural choice for a web application server and development environment. Bernie Thompson, President of VistaSource, said "we got 120,000 hits on launch day (max 14,000 hits/hour), which was the peak. Zope handled the load fine."

Case Facts

VistaSource brought 6 people, working a combined total of approximately 200x hours, to bear during the 7 day period. Persons responsible for content received only minutes of training to become familiar with the Zope management interface. Persons responsible for back-end programming had only 2-3 days of prior Zope exposure.

Problem

Due to time constraints, VistaSource needed to be able to begin producing content in parallel with the developing the site's look and organizational layout. In addition, deadlines required the use of high level functionality, with no time available to evolve a custom suite of tools out of a lower level solution.

Solution

The VistaSource.com site was launched using built-in functionality of Zope's DTML, with additional Zope Products including TinyTable, NFGNav, and Redirector.

Three major features of Zope stood out during the development process:

Templating and Acquisition

In order to perfect content and aesthetic considerations simultaneously, VistaSource.com designers developed a template index_html method, which used DTML to include other templates as well as content. Each folder in the site then provides body contents and may override specific portions of the site's look, simply by providing the appropriately named template.

Acquisition's ability to model more than simple inheritance, by providing a namespace stack, allowed commonly included objects to be stored in separate folders, yet kept transparently in the acquisition namespace. As a result, content work was possible without yet knowing the site's organization. A document could link to others and include images, without the usual HTML dillemas of using absolute or relative paths, by relying on acquisition to discover the location of the other objects automatically.

Undo and Versions

Having been forced to "dive in" without a clearly defined concept of the site's design, the transactional nature of the Zope back-end proved indispensable. Contributions could be made by any one of the maintainers, and if the consensus of maintainers was that the change wasn't positive, it could be rolled back. As only a minority of changes ever needed to be rolled back, developing with this relaxed workflow was critical to the efficient evolution of the site over the 7 days time. Even relatively low-overhead email polls of all the site developers to get consensus approval for changes would have often held additions to the site up longer than was tolerable.

Similarly, Versions provided site developers the ability to explore "what-if" scenarios, learn more about Zope without interrupting other work, and gave the site the ability to be developed, in-place on its server, while the public was only able to see a brief "teaser" with the launch date. This last use of Versions effectively eliminated an entire class of potential launch bugs, by ruling out the possibility of error when installing the final site elements and removing the teasers: Versions provided the literal assurance that the users would be seeing exactly what the developers had been working on.