Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Switching from PHP to Zope/Python

By salimfadhley in Technology
Tue Mar 23, 2004 at 05:18:06 PM EST
Tags: Technology (all tags)
Technology

Occasionally, when working with computers, you get to experience a completely new way of thinking about problems long thought solved. Rarer still does one find a new set of solutions that are so well thought out and integrated that older approaches seem clumsy by comparison.

Recently I discovered Zope, and having understood its principles I decided to abandon my years of PHP experience in pursuit of a better way.


The problem with scripting

In my former incarnation as a PHP programmer, I re-invented the wheel most working days. Is there a scripter who has not built classes for basic tasks like database connections or representing content? When I analyzed the time I spent coding, I realized that much of it was spent solving routine problems. I needed was a way to take the routine out of my work.

A wise PHP coder worth his or her wage will make use of standard classes: Pear, Smarty and ADODB provide bigger building blocks with which to construct a project. These do not fundamentally change the way we program - but they do save programmers from some of the excruciating detail. Once you are familiar with these classes it's not so hard to work out a routine way of joining them together, and perhaps more than a routine ? you build a standard set of libraries for dealing with your day to day work.

What's so bad about having your own Application server or Content Management System libraries? With them you can construct a number of similar projects. But what about the client who wants something completely different? Do you find a way to extend your system? Do you write something new from scratch or do you find a way to shoe-horn the project's brief into the capabilities your older code?

The Zen of Zope

Wouldn't it be nice if there was a sufficiently flexible framework built and maintained by somebody else ? You might use a package like Zope for the same reason that most people use a Linux distribution instead of manually assembling packages from the author's TGZ files.

For example, nearly every system on the web needs a templating system: Zope provides two contrasting approaches to templates (DTML, ZPT) - despite their differences they both have similar APIs and can be programmed in much the same way. As a result I can use them interchangeably.

Zope also provides a number of data source objects - A standard object called a 'ZSQL Method' can be used to query any database connection and can be combined with either form of template to build a simple database querying and presenting application with almost no programming.

Since the objects are all work together in a standard way, I need not concern myself with how I am going to make everything work together but what exactly I want to do with it. Instead of re-inventing the wheel I get to drive the car.

What is Zope?

Zope is an Object Publishing Environment, a kind of application server that allows you to easily re-combine objects in handy ways to achieve your goal. Everything in Zope is an object, from a document to an error message. At the core of Zope is a simple object request broker - a program that knows how to match objects to user requests and deliver results over an Internet protocol.

Every object in Zope inherits from a few ancestor classes that define the most basic aspects of an object's API. You know for example that every container object behaves much like any other kind of 'folderish' object. Having understood the general interface of containers the chances are you will be able to use all containers.

These are some of the components that come in the basic Zope distribution:

  • ZODB - An object oriented database to store your code and content. Superficially it is like a filesystem - but thanks to a feature called acquisition it can allow objects to appear in more than one location. This bizarre feature allows programmers to quickly call up the most appropriate object based on the 'context'.
  • ZMI - The Zope management interface, a Zope based web application that lets you build more Zope web applications. Developers can manipulate the ZODB by placing and editing Zope objects.
  • WebDav / FTP interface - An alternative to the ZMI interface that allows you to continue using your favourite integrated developers environment to program Zope. The ZODB pretends to be a traditional filesystem that allows developers to quickly upload and change content.
  • Document and Template Classes - These provide standard ways to represent documents and present data. In Zope 2.x there are two main kinds of template, however in future there are plans to unify both models.
  • Data Access Classes - You can access a data-connection class using a ZSQL method. These are sources of data that can be catalogued, filtered and presented by other classes.
  • 'Utility' and 'Service' Classes - These provide a wide range of helper functions, such as error logging, indexing, sending and receiving email.
  • Products, Scripts and External Methods - These provide ways to extend Zope using the python programming language. A Product is usually a set of objects with a management interface. Scripts and external methods are more like functions in a procedural language.

Most development does not require access to the host operating system. A Windows Zope server looks identical to a Linux Zope server. Zope is a good option for developers wishing to opt-out of the platform wars.

Zope is more than a replacement for your favorite scripting language, its a completely object oriented environment geared to building better applications.

Persistence

Zope users take for granted things that are harder in scripting languages. For example, persistence of objects and variables.

The usual method of making things persistent is to use a session class, or perhaps a class of your own concoction that writes things that need to persist into a relational database. Once again, Zope does not prevent you from this kind of traditional solution, but as usual it provides a much easier way.

Zope is built around the ZODB, an object oriented database that transparently saves and loads Zope objects. As a result, allowing some data to persist is simple as setting a property or writing an object. No need to worry about SQL, extra classes or database-commits, it just works 'out of the box'.

Your code can be more reusable

Experienced scriptwriters will usually write their classes in a generic way that can then be sub-classed with configuration information. In this way the class and its configuration can be kept in separate files. This is an effective kludge, but does mean that anybody wishing to use that class needs intimate knowledge of what variables to set.

Once again, Zope does not forbid this traditional scripting technique, but it does allow a more powerful means to define generic components: A Zope Product is the standard way of extending Zope's behavior.

A product is a self-contained bundle of code that can includes administrative interfaces, user interfaces and the classes that make it work. From the Zope programmers' point of view, once built, a product is merely something that can be dropped into a container and used much like any other object.

The beauty of this system is that what the Product does is kept in a completely different domain to how a particular instance of the object is used. Re-using code in Zope is usually as simple as placing an object and setting some configuration options on it.

Zope is secure by design

Web applications are infamous for their vulnerabilities; writing good security is hard, and when deadlines are tight, security will often be left until the last minute. As a result, most web applications have poor security.

Zope lets you turn the situation around. It gives you a declarative security model, which makes security an intrinsic feature of anything you build:

As with any object oriented environment you can inherit features of older objects into new objects. Having built an excellent security model, all of the Zope objects can automatically take advantage of it.

You protect Zope objects with permissions, and you grant permissions to users or groups of users; All this can be defined separately from your descriptive object code.

Of course, if you want to invent new types of permission or a new security model, there is nobody to stop you.

Zope makes data easy

I mentioned before that Zope is built around something called the ZODB, an object oriented database. This is a great start for most web applications, which tend to be organized hierarchically. OODBs tend to be more suited to applications where rules governing data frequently have exceptions.

Of course nobody is forcing you store everything as objects. Zope comes bundled with a basic relational database called Gadfly, and with the addition of a Data Adapter (e.g MySQL, Postgres) you can use pretty much any relational database on the market.

People who use scripting offer database abstraction layers to make talking to a database less of a nightmare. PHP has at least two excellent abstraction layers (ADODB and Pear DB). Zope gives you abstraction, plus the ability to define of connection objects and query templates visually.

ZSQL combined with Connection objects allow you to define SQL templates that can be run as a query. Any ZSQL method becomes a source of data. Consequently it can be chained to other objects that know how to process, catalog or display that data.

Zope plays nicely with your existing tools

A basic of Zope's design is to offer an alternative without forcing you to abandon standard tools and techniques. Contrary to popular belief, you do not have to give up Apache or your favorite editor. You do not have to do everything through a web interface.

Zope's FTP and WebDav interfaces allow most development environments to connect directly to a Zope-server. This bypasses the web interface, which is not appropriate for large text processing tasks. Macromedia Dreamweaver, Front-Page and KDE Kate can deal with objects in Zope as if they were normal files in a file system.

The Virtual Host Monster provides a safe way for Apache and Zope to co-operate. This utility class allows seamless remapping of Apache virtual hosts to points in the ZODB. It allows you to turn a single Zope-instance into a number of virtual Zope instances accessible via Apache's mod_proxy.

Summary

Zope is a beautifully integrated set of solutions to common web development problems. It works in a substantially different way to traditionally scripted web-applications. Think of it as a collection of objects help with web publishing rather than a set of scripts to do a job.

Zope objects are designed to work well together. Instead of wondering how best to make one class talk to another you can go ahead and build your application.

By making use of a well developed, stable platform in which the common problems have already been solved, you are free to concentrate on a problem's unique aspects.

Getting Started

  • Downloading Zope - Or use your Linux package manager to download it for you. e.g. Gentoo: just type 'emerge -uDvp zope', check your use flags and if everything is good to go 'emerge -uD zope' will give you what you need. Debian: 'apt-get install zope'
  • Zope Tutorial (Link is on your Zope Installation welcome screen) - There is a built-in interactive Zope Tutorial which gets you started with some simple tasks using the Zope management interface. To use the tutorial, go to any Folder and select Zope Tutorial from the add list and click the Add button. Provide a name for the tutorial and click Add to begin working with the tutorial.

Getting Help

  • #Zope on Freenode (IRC) - A friendly forum that frequently visited by Zope developers.
  • #Python on Freenode (IRC) - A group of people who can help you with your python scripting problems.

Other Zope Resources

  • The Zope Book - Do not buy any Zope books until you have read THE Zope book. By far the best introduction to Zope development.
  • Zope Newbies - A blog to help you through your first few days of Zoping.
  • Python Tutorial - Since Zope is a pure Python application, the more you know about it the more you will understand.
  • Nobody Expects the Spanish Inquisition - A compact intro to the Python scripting language, courtesy of K5.

Interesting Zope Apps & Products

  • Plone - A skinnable content management system built in with Zope and the Content Management Framework.
  • Silva - A rival Zope based content management system that makes novel use of XML.
  • DocFinder - An automatic documentation system that allows Zope to look within itself to show you how the basic objects and products work.
  • Product database - A collection of products that extend Zope's capabilities.

Praise be unto Altair from #zope for assisting with the proofreading of this document.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
What will you be using to build your next web project?
o Perl/CGI 5%
o mod_perl 8%
o PHP 38%
o mod_python 2%
o sh/CGI 2%
o Java 21%
o Zope 15%
o Other 5%

Votes: 71
Results | Other Polls

Related Links
o Zope
o PHP
o Pear
o Smarty
o ADODB
o Linux distribution
o DTML
o ZPT
o ZSQL Method
o folderish
o ZODB
o Zope Product
o declarativ e security model
o MySQL
o Postgres
o Downloadin g Zope
o The Zope Book
o Zope Newbies
o Python Tutorial
o Nobody Expects the Spanish Inquisition
o Plone
o Silva
o DocFinder
o Product database
o Also by salimfadhley


Display: Sort:
Switching from PHP to Zope/Python | 133 comments (86 topical, 47 editorial, 0 hidden)
I tried Zope, and hated it (2.33 / 12) (#17)
by emwi on Mon Mar 22, 2004 at 10:23:24 AM EST

-everything is stored in one big file
-the web interface sucks-how do you use an external editor?
-it runs on its own port, a lot of company networks block ports - tried a workaround which made Apache proxy a directory to Zope, it was buggy and awful and never really worked.
-unreproducable error messages occured frequently. Doesn't make you feel it's ready for your production system.
-The manual was outdated. The help you get sooner or later comes down to "do it in python".

Summary: You start because you want a CMS to avoid programming it all by yourself. In the end, you start fixing the CMS, having more headaches with a blackbox instead of fixing your own code.

Switched to PHP, loved it since then. Why don't you encapsulate your Database/HTML formatting code and reuse it on later projects?

corrections (2.88 / 9) (#19)
by salimfadhley on Mon Mar 22, 2004 at 01:03:43 PM EST

-everything is stored in one big file... unless you decide to store things in a regular filesystem or a database.

-the web interface sucks - so just use your favourite IDE.

 -it runs on its own port - so you can continue using apache. The virtualhosting tools are now very stable.

 -unreproducable error messages occured frequently ... possibly on a broken install.

 -The manual was outdated... because the programmers are constantly improving the system.

[ Parent ]

Yeah - how DO you use an editor? (3.00 / 5) (#25)
by mr strange on Mon Mar 22, 2004 at 06:00:55 PM EST

(I tried Zope a year or two ago, and felt I didn't have time to learn it.)

Using a normal editor was never mentioned (IIRC) in the tutorial. I admit that the web interface is superb, but I'd still rather have my favourite editor. Can anyone enlighten me?

In fact, the online tutorial was pretty crap from my perspective. Lots of baby food, without any helpful pointers to what was REALLY going on inside Zope. Made me feel like driving a sluggish American SUV with soft suspension and sloppy power steering. No real feel for the road.

I suspect that Zope is actually elegant and pretty simple to grasp. Shame the tutorial didn't help me much.

intrigued by your idea that fascism is feminine - livus
[ Parent ]

Wrong (2.81 / 11) (#27)
by spakatak on Mon Mar 22, 2004 at 06:24:34 PM EST

> everything is stored in one big file
You have the option of storing data inside the ZODB if you wish. You can also store data inside an SQL database or on the filesystem. the choice is yours.

> the web interface sucks-how do you use an external editor?

If you are writing any serious amount of code, you work directly on the host operating systems filesystem, NOT the zodb. as such, you can use any damned editor you want.

If you insist on writing code directly into the ZODB, you can use WebDAV, FTP, or a product called "External Editor" that transparently integrates with zope and the client operating system to allow editing with your favorite application.

> it runs on its own port

The default port is 8080 as to not conflict with Apache. If you want to run it on port 80, then just edit the config file.

> unreproducable error messages occured frequently

I've been developing in zope professionally for two years, and have never had that problem.

> The manual was outdated

Keyword: WAS. It has improved tenfold in the last year or so.

> Summary: You start because you want a CMS to avoid programming it all by yourself. In the end, you start fixing the CMS, having more headaches with a blackbox instead of fixing your own code.

Zope is NOT a CMS. Zope is an Application Server like Tomcat. You can write using as much, or as little of the default libraries as you wish. You can write in pure python without knowing zope exists if you feel like it. You can even write zope applications in PHP, Perl, Java, C.... anything you like.

> Switched to PHP, loved it since then. Why don't you encapsulate your Database/HTML formatting code and reuse it on later projects?

PHP is a perfect example of a badly designed programming language. You don't have a decent templating language. There is virtually no common libraries. String manipulation functions are riddled with errors. Major incompatibilities creap up between point releases. No concept of namespaces. I could go on for hours.

[ Parent ]

answers (none / 1) (#58)
by emwi on Tue Mar 23, 2004 at 05:38:18 PM EST

> everything is stored in one big file
You have the option of storing data inside the ZODB if you wish. You can also store data inside an SQL database or on the filesystem. the choice is yours.

So there is a way to store my objects in single files and edit them there (except the xml export option of course)? I might have overlooked it, after all, but it was definitely not mentioned in the documentation.

> it runs on its own port

The default port is 8080 as to not conflict with Apache. If you want to run it on port 80, then just edit the config file.

And that means I have to store everything, even index.html and logo.jpg, as an object in the above mentioned one big file, which is why everyone recommends to use Apache and Zope simultaneously.

> unreproducable error messages occured frequently

I've been developing in zope professionally for two years, and have never had that problem.

Well, I had, most often with some awkward error message from zope's database. Clicked reload and it disappeared. With "frequently" I mean one in every 50 clicks or something.

PHP is a perfect example of a badly designed programming language. You don't have a decent templating language. There is virtually no common libraries. String manipulation functions are riddled with errors. Major incompatibilities creap up between point releases. No concept of namespaces. I could go on for hours.

But it does what it should do quite well: Make stupid HTML pages intelligent. All the things you say sound reasonable, and yet I am very satisfied with the amount of time invested compared to the results.DTML is horrible as anyone admits. Python might be the latest and greatest, but first of all it uses a new syntax and error messages in Zope won't give you a clue what you did wrong, not even the linenumber! PHP does that. Sometimes, this makes a good programming language.

[ Parent ]

wrong (none / 2) (#67)
by spakatak on Wed Mar 24, 2004 at 12:01:02 AM EST

Zope has an excellent error management system. It just doesn't reveal detailed internal debugging information to the john doe who caused the error- it's a potential security risk. Use the error log. It gives extremely detailed information. The main issue I have with PHP, JSP etc is the insertion of raw code into html- It always ends up messy. You should always seperate your presentation and logic layers, and I have yet to find a better way to do this than zope page templates. DTML sucks. Nobody uses it anymore.

[ Parent ]
Justifying the bad implementation... tsk tsk (none / 0) (#125)
by smagruder on Wed Mar 31, 2004 at 02:43:50 PM EST

It just doesn't reveal detailed internal debugging information to the john doe who caused the error- it's a potential security risk.

This folks is what is known as a black box. If you're a decent programmer who prefers flexibility, avoid it at all costs.

Steve Magruder
True Democracy = True Freedom
[ Parent ]

One Big File designs suck (none / 1) (#64)
by Maserati on Tue Mar 23, 2004 at 10:31:45 PM EST

http://hathaway.freezope.org/Software/Ape Ape adapts Plone to map objects to the filesystem. TikiWIki (built on Plone) appears to be in a state of confusion about storing things in the filesystem One of the devs would like everything in the database, which has a lot going for it. I'm looking for a CMS that I can let people throw hundreds of scans into (up to 40 MB each). Hmmm, filesystem or MySQL for that ? http://tikiwiki.org/tiki-index.php?page=DataAndSettingsInDatabaseDev#comments

--

For the wise a hint, for the fool a stick.
[ Parent ]

Is there an ANSI/ISO Zope standard (1.75 / 4) (#30)
by lukme on Mon Mar 22, 2004 at 09:34:24 PM EST

If not there should be. I cannot wait to read it. I wonder if it would be longer than the C++ standard?

Seriously, though, your entire artical makes me think of the arguments for using C++, and then the Standard Template Library for C++, and then Java (whatever the buzz words of the day), ... .

This sounds like a great tool to learn when you manager says we are now programming in Zope.


-----------------------------------
It's awfully hard to fly with eagles when you're a turkey.
+1 SP when it goes to voting... (1.11 / 9) (#33)
by alby on Tue Mar 23, 2004 at 04:54:00 AM EST

... not that I understand a word of it.

--
Alby

Code complexity (2.85 / 7) (#40)
by n8f8 on Tue Mar 23, 2004 at 08:01:07 AM EST

What I didn't like about systems like Zope and even off-the-shelf content managment systems is the bloat factor. Chances are that the system does like 100X what you really want it to do. But the stanrd base install throws in the whole mess. Often the coding syle is inconsistant so debugging is a pain in the ass. Not to mention the overhead of all the redundant junk.

I've written a content managment system in 15 pages. One index file, one css/stylesheet, one js file, two each for story, comment, user, standard functions, calendar and event. This includes a complete implementation of Julian-Gregorian-Unix time conversion functions and a calendar to implment them. Each file is between 20KB and 30KB. All database classes inheret the same database class. Got a problem -you don't have to waste time hunting it down.

Sig: (This will get posted after your comments)

Nothing beats homemade. (none / 2) (#43)
by waxmop on Tue Mar 23, 2004 at 10:02:31 AM EST

I think the value of learning ZOPE comes in situations like the author described at the beginning, where you have to extend your app to support some completely unexpected new feature, one that may require an entirely new design. ZOPE will most likely already have what you're looking for, and you can just enable a new module. There's no need to do a complete redesign.
--
Long-term consequences of Bush deficits

[ Parent ]
Good point, but (none / 2) (#46)
by salimfadhley on Tue Mar 23, 2004 at 10:49:16 AM EST

If your system will never have to grow or evolve from it's first revision then you will get no benefit from using a big app-server like Zope.

I too wrote a PHP content management server that started out as less than 10k of code. In the end I found that from my clients point of view they would rather I use a standard platform for work that another programmer is likely to understand quickly.

[ Parent ]

It's the flexibility! (none / 0) (#126)
by smagruder on Wed Mar 31, 2004 at 02:51:46 PM EST

If your system will never have to grow or evolve from it's first revision then you will get no benefit from using a big app-server like Zope.

Horsefeathers. On the contrary, a well-designed flexible framework developed in PHP can easily be extended to cover new needs. That's the point of total flexibility over the vaunted "black box" that you have virtually no control over.

Steve Magruder
True Democracy = True Freedom
[ Parent ]

Zope is great, really it is. (2.62 / 8) (#49)
by regeya on Tue Mar 23, 2004 at 11:59:22 AM EST

It's important to point out that it's a real resource hog, though, and that a pure Zope solution is much slower than a traditional LAMP solution.

Read up on it: many fair-sized Zope installations use Apache to serve up largely-static pages, images, and use a SQL server for storing most data. Um, and the point of using Zope was what, again? You could also run Zope behind something like Squid, which makes more sense to me, and store large files in the filesystem. If you dig deep on the Zope website, some Zope developers don't recommend storing images at all, and don't even recommend using the ZODB as a database! What was the point of using an object database as the default storage system, again?

Don't get me wrong. I use Zope for an in-house system. I wouldn't consider it for a general website, though, until more efficient storage solutions exist, and I'm considering moving everything over to a PostgreSQL/Apache solution anyway.

[ yokelpunk | kuro5hin diary ]

Hmm (none / 2) (#66)
by spakatak on Tue Mar 23, 2004 at 11:49:36 PM EST

A moderately complex zope site can handle well over 100 requests per second on a 1ghz P3- Without sticking Apache/Squid in front and without using an external database.

[ Parent ]
And Apache/PostgreSQL... (none / 0) (#95)
by MyrddinE on Wed Mar 24, 2004 at 02:18:39 PM EST

... on the same hardware could probably server 2-3 times as many requests per second. Too be honest though, I think your example of 100/second for Zope is optimistic. I'd have said about 30-50/second on that hardware. Oh, and don't forget the huge HD needed to support the ever-growing db.

[ Parent ]
Not always (none / 3) (#107)
by spakatak on Wed Mar 24, 2004 at 08:12:50 PM EST

A lot of complex PHP systems I've used a extremely slow. I found Plone to run 2-3x faster than PHPNuke, and simple adding a RAM Cache Manager to your site (a point and click affair), your zope server will work out when it can safely return a cached copy of a document and it can quite easily compete with Apache.

The problem with LAMP solutions is SQL is slow. Sure, if your joining two tables with a million records each it's going to walk all over anything the ZODB could come up with, but for simple requests for one record (i.e. SELECT * FROM USERS WHERE USER = 'bob') and then parse it into a usable data structure the overhead actually makes it slower, as the ZODB just has to return a pointer.

If your Zope server is overloaded, you just plug another one in and spend 30 seconds configuring ZEO. Done. It scales to any size transparently. You can even use ZEO to mirror your zope site around the world transparently. MySQL can't do that.

When we're talking enterprise systems, the cost of a new x86 box is trivial. In either case, both Zope and Apache can saturate a 10mbit link, so the difference is acedemic.

I can develop much more complex applications a hell of a lot quicker in Zope than LAMP.

[ Parent ]

Sure can't argue... (none / 2) (#87)
by DDS3 on Wed Mar 24, 2004 at 10:35:59 AM EST

....with a PostgreSQL/Apache solution.  Speed and stability is hard to counter.


[ Parent ]
Zope and acquisition... (none / 3) (#51)
by claes on Tue Mar 23, 2004 at 12:12:58 PM EST

The strangist part of zope is also one of the coolest: Acquisition. If you're down at /Reports/Asia/China/Navy/NewShips.dtml (a web-page template) and you reference a variable called map, Zope will search upward through the tree, looking in Navy, then China, then Asia, then Reports, for the variable called map. This (well, along with persistence) makes zope zope.

To paraphrase someone, those who do not understand acquisition are doomed to re-invent it, poorly.

-- claes (longtime zope zealot).

Acquisition sucks. (2.33 / 6) (#54)
by tkatchev on Tue Mar 23, 2004 at 02:14:48 PM EST

Really, really sucks.

The concept of "acquisition" basically means that you've thrown any concept of modularity and code re-use out the window.

Anything that is even a bit more complex than your contrived example with maps or circus animals or kindergarten shapes or whatnot is doomed to degenerate into a giant morass of a thousand little objects that are almost verbatim copy-pasted code, except for a few bits of incomprehensible code with cryptic inherrited global variables.

Zope failed to meet its design objective and is unsuable for medium-to-large sized projects.

Don't use Zope.


   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

I don't agree... (none / 1) (#55)
by claes on Tue Mar 23, 2004 at 02:24:31 PM EST

Because as well as variables you can have methods up in the tree to be acquired. You use a common name for the method, and put the right one in the right place. header, footer, navbar, whatever.

Acquisition is only a part of zope. The package setup is pretty nice. We manage bug tracking for a number of projects with a common bug-tracking zope package (bugs are in a database). Works fine, very stable (current uptime is 98 days, just like the server (Linux (good, I'm geeking out)). It is pretty easy to extend, also. I had to add multiple projects about 2 years back, and it wasn't all that hard to do.

But in a way, you're right. Doing a project where the application objects are python objects in the zodb is interesting, but can get twisted fast. At some point you just bag it and stick the data into a database and use zope for presentation.

But to say "Don't use Zope" is a bit of an strech.

-- claes

[ Parent ]

I say "Don't Use Zope" (2.33 / 6) (#59)
by rho on Tue Mar 23, 2004 at 06:24:44 PM EST

It's too hard to deal with, especially if you might not be around in a year or two. Any person who develops an application without thinking about the future is a fucktard, and should have his fingers braided together, and your schmancy Zope application will be useless when you get hit by a bus and there's nobody around to hire that can understand it.

Zope is a good white-paper. It's a great demo. It's also unusable for too many because it's academic. A partner of mine, a Python zealot, found Zope too big a pain to deal with. He didn't understand the objects, because they're not so much written in Python as they're written in Zope, and the DTML has about as much relation to HTML as I do to a radish.

The work we do together now involves a mishmash of Python and PHP, depending on who's writing what. Know what? It doesn't matter. Important data is in the database. Text files will either be in PDFs or HTML files. (Just plain HTML files, no fancy formatting, thank you.) The rest of the mechanism behind it is just that--mechanism. Who gives a shit whether the New York Times is printed on a big ol' web press or laid by a giant grey chicken. As long as we get the good stories above the fold and the crossword, it doesn't matter, and anybody who ignores that and fixates on the printing press is a moron and a wanker.
"The thought of two thousand people munching celery at the same time [horrifies] me." --G.B. Shaw
[ Parent ]

Pretty bold statement. (none / 0) (#65)
by DDS3 on Tue Mar 23, 2004 at 11:09:45 PM EST

I've looked at Zope too.  I've never figured out if I like it or not.  Just the same, you've made some pretty bold statements.  Care to back them up with something other than well stated opinion?


[ Parent ]
OK, I'll try. (none / 0) (#81)
by tkatchev on Wed Mar 24, 2004 at 06:42:08 AM EST

A common stumbling block that is bound to happen in any web application that is sufficiently large:

/Animal
|
  /Animal/Elephant
  |
    /Animal/Elephant/White_Elephant
    /Animal/Elephant/Pink_Elephant
    /Animal/Elephant/Striped_Elephant_With_Wings

With Zope, there is no way of sharing code between the different types of elephants without dumping all the relevant code into "/Animal/Elephant". (Which basically destroys any notion of modularity or code reuse.)

Now imagine the case where you might have a couple hundred of such structures in a complex, intertwined network of pages.


   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

umm (none / 1) (#82)
by spakatak on Wed Mar 24, 2004 at 07:21:32 AM EST

I don't follow your logic. The simplest and most logical solution IS to dump the shared code in to Elephant. Thats a basic OO principle.

In any case, that situation is best solved with Inheritance (Which any OO programmer should understand) rather than Acquisition, which is more suited to Content, not Code.

i.e., you would, say, put a standard header at the root of your site called "header". if, in a particular subsection you wanted to use a new header, you would just put it there and it would acquire it transparently. Of course this is only a simple example, there is a lot more to it than that.

[ Parent ]

That may be "simple" solution... (none / 1) (#93)
by tkatchev on Wed Mar 24, 2004 at 12:52:31 PM EST

...but from a software engineering viewpoint (and from the viewpoint of anyone with a shred of common sense) it is about as useful as dumping all your code into one giant file with no functions or local variables. (Like GW-BASIC.)


   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

No (none / 2) (#103)
by spakatak on Wed Mar 24, 2004 at 07:35:22 PM EST

It's like putting shared code in a common base class.

[ Parent ]
Correction: (none / 1) (#111)
by tkatchev on Thu Mar 25, 2004 at 06:26:08 AM EST

Putting all your shared code in a common base class.

   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

Yes (none / 1) (#115)
by spakatak on Fri Mar 26, 2004 at 02:10:12 AM EST

All shared code should go in a common base class. Unless you happen to want it to go somewhere else, which you can do so as well.

I really think you a) aren't grasping a fundamental OO concept and b) are trying to treat acquisition like inheritance and design an OO system around it, which is not what it's made for.

The ZODB contains content. Code lives on the filesystem. Code is written in a fully object orientated language. Do I make myself clear?

[ Parent ]

No. (none / 1) (#116)
by tkatchev on Fri Mar 26, 2004 at 05:05:50 AM EST

I understand OOP very well.

The problem is that if "OOP" interferes with good programming practice and impedes modularity, then OOP needs to go.


   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

ok (none / 1) (#118)
by spakatak on Fri Mar 26, 2004 at 07:27:02 AM EST

But how on earth does acquisition interfere with good programming practice and modularity?

[ Parent ]
Well, (none / 1) (#119)
by tkatchev on Fri Mar 26, 2004 at 09:50:58 AM EST

Precisely in the fact that it does not allow (moreover, it expressely forbids) having modules.


   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

Umm (none / 1) (#122)
by spakatak on Sat Mar 27, 2004 at 12:36:46 AM EST

What the f*ck are you smoking? You develop for Zope in PYTHON, a highly modular language. It explicitly FORCES you to use modules.

[ Parent ]
Hmmm.... (none / 0) (#86)
by DDS3 on Wed Mar 24, 2004 at 10:33:45 AM EST

I can't seem to understand why you wouldn't want to do that.  It even makes sense to do that.  Seems like everything that is generalized about elephants should seemingly, be in the highest level of elephants.  Specifics, that relate to distinct elephant types, belong there.  Help me understand why you wouldn't want that.  Please.

Perhaps I'm thinking too OO, but your example of bad seems to make a compelling, "nothing but goodness", case.


[ Parent ]

Uhm... (none / 1) (#94)
by tkatchev on Wed Mar 24, 2004 at 12:53:32 PM EST

...because in this case I would have 1000 little bits of unrelated but very similar copy-pasted code in "Elephant"?

Duh?


   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

Uhm.... (none / 0) (#97)
by headqtrs on Wed Mar 24, 2004 at 03:39:13 PM EST

If everything belongs to elephant it should be coded in elephant and all bits relate to elephant. Your comment doesn't make sense (and no, repeating it does NOT make it any better).

[ Parent ]
Look here. (none / 1) (#98)
by tkatchev on Wed Mar 24, 2004 at 04:00:14 PM EST

Zope does not support modularity nor code reuse.

If you can refute me, please do so.

(And no, the half-assed, confusing concept of "acquisition" is not modularity.)


   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

my refute (none / 3) (#105)
by spakatak on Wed Mar 24, 2004 at 07:55:14 PM EST

Well, let me see.

A sales system I'm currently developing has 28 modules, each of which contains 1 class. Each class contains  numerous procedures, and there is a fair bit of inheritence.

There are also 89 Page templates, which are used to manage the system and provide and interface for various levels of management.

All this is on the filesystem. I edit it using my favourite IDE (KDevelop). It uses a JIT compiler called psyco to process data several times faster than the equivilant Java code, and it uses much less memory.

In accordance with good design practices, the presentaion layer (the page templates) have absolutely no business logic. They simply make calls into the python code which returns python data structures that the page templates render. They are incredibly easy to develop and are clean and elegant.

The code is clean, easy to manage, well designed, modular, and very scalable. The system grew from a tiny shopping cart to a full blown sales and client tracking system with, well beyond it's original design specs,  with absolutely no major bugs and minimal growing pains. The ease at which it scaled is a testament to the power of Python and Zope. It handles several hundred requests per second on a 1ghz machine with 256mb RAM, and an average response time of 11 ms. I ran such a benchmark, pushing the server to it's limit, for 48 hours with no problems at all.


[ Parent ]

Examples would be nice (+ more!) (none / 1) (#57)
by treetops on Tue Mar 23, 2004 at 04:29:57 PM EST

application server that allows you to easily re-combine objects in handy ways to achieve your goal

I wish I knew what exactly that meant. Sounds kind of fluffy to me. Could you give examples how this works, and why it's better than simply re-using class libraries like PEAR?

I looked at Zope years ago, but it seemed hard to grasp, possibly owing to the poor documentation and interface of earlier versions.

You also didn't mention FreeZope, where anyone can sign up for a zope site.
--tt

I've tried it twice. (2.71 / 7) (#60)
by ghjm on Tue Mar 23, 2004 at 07:31:11 PM EST

The first time was quite a few years ago when Zope was pretty much the only major project using the Python language. Then I met some Zope guys at a conference. They were icky - you know how some trade show booths have that creepy, cult-like aura? They just came across as self-satisfied, insular freaks. It just turned me off to the whole thing.

So I tried it again much more recently, and found it to be a very Java-like experience. It's a big system: It takes a lot of effort to learn how all the parts work together, get it all configured, and make it perform in a production environment. Unlike Java, there's no ready pool of contractors to work on your project. The supposed benefit is that once you get it all together, there's a major productivity boost.

In fact, what I've observed is that productivity remains about the same, but the mental space that's supposed to be directed towards understanding customer needs is now directed towards managing your conceptual map of the Zope framework. Customer needs have to be adjusted to fit the capabilities of the model - you hear statements like "okay, this is what we can do for you" followed by an explanation of how some pre-built Zope component works. In this regard it's not as much Java-like as VB-like, from the VB3 era where all people wanted to do was wire up VBX custom controls to client/server databases.

The PHP/Apache guys are a pain in the ass because they like to write a new content management framework for each project you give them, so if you lose the guy who originally wrote the project, it's going to take three to six weeks to get the next guy genuinely up to speed - and he'll probably rewrite most of the code along the way, because he didn't understand how the old system worked. But at least they have a clear head when the customer wants to talk, and at the end of the day the final output somewhat matches what the customer described.

-Graham

a little late, but... (1.75 / 4) (#61)
by kpaul on Tue Mar 23, 2004 at 07:51:47 PM EST

+1FP. it seems my k5 comrades voted my will in my absence ;)

seriously, though, nice job. k5 needs more of this...


2014 Halloween Costumes

Take another look at Perl (no, really) (3.00 / 10) (#63)
by lilnobody on Tue Mar 23, 2004 at 08:04:16 PM EST

Perl has gotten very good for creating the kind of apps you describe without any of the problems people complain about below. All of the advantages you describe above exist in Perl with a lot of poking on CPAN. All with standard Perl modules, all without sacrificing the ridiculously large (sometimes too large!) amount of library code out there for Perl.

You say you might pick Zope the same way you might pick a distribution, but Zope gets into everything--it gets into Apache, it gets into the editing with its web interfaces. It tries delve into every layer of production, from code to content to delivery. It even politely requests of you to use its security model, which you can replace--just write a new one. No problem! That's not like picking a Linux distribution, that's like buying a far overpriced box at CompUSA with Red Hat pre-installed.

You talk about 'the problem with scripting'. I think your problem is that you aren't using your tools correctly. Take Perl, only as good or only as bad as you want it to be. I have seen some --bad-- f-ing code out there for Perl, but that isn't Perl's fault. Perl is as OO and well-behaving as you want it.

Every time I start a major Perl project, I see whats new. Nowadays, I'm using Template Toolkit, CGI::Application, and Class::DBI.

Template toolkit is an oldie but goodie that is just a strong templating system--html files with [% variableName %] tags in them. But [% obj.method.method.method.field %] works just fine too, with TT finding out whats a reference, method, or field along the way, transparently. Still among the best of the template systems for any language.

CGI::Application lets you keep all your application code in one file but basically takes care of all of the 'forking' code for you. Makes one's code quite pretty and maintainable, while sacrificing a bit of flexibility. I find it's worth it for web stuff.

Class::DBI basically does what it seems like the author is in love with Zope over, that is, tying objects to databases. You extend Class::DBI, associate a few columns with fields, and go nuts. A lot of my objects are less than 5 lines of code, and I don't touch SQL unless it gets quite complicated. All without goofy web interfaces.

Here is a good intro to the three libraries given above. They do plenty more, though.

At least you got rid of PHP, though. PHP 5 is all about turning PHP into Java, while still managing the model of code directly in web pages. I know that PHP supports templating systems and all, but it doesn't seem to be the focus of the developer community to write that kind of code. Anyone who has ever tried to customize the rather popular OSCommerce package knows what I'm talking about, here.

All in all, I just don't get why web technologies keep getting re-invented. Servlets sacrificed simplicity for better performance under big loads, and I can understand that. There's people out there trying to make Haskell and other languages with different paradigms into CGI workhorses, and I can follow that too. But what is the point of yet another web development system? It's just a fucking web browser, it's not going to do anything new. Perl's been doing it for years. What's the problem exactly?

ben

Perl OO (2.80 / 5) (#70)
by Coryoth on Wed Mar 24, 2004 at 12:34:02 AM EST

Having used both Perl and Python fairly extensively, I would have to say, if you want to do serious OO work, give me Python any day.  Perl's object system is quite flexible, and very practical for a lot of purposes - it certainly makes things far cleaner in many cases, but in the end it does start to show that the OO is patched onto Perl, while Python is OO from the ground up, and plays far nicer in all respects.

Which is not to say you can't do everything in Perl that you can do in Python - it just isn't always quite as clean and easy.  Likewise, Python has a very nice regex engine, but it just isn't merged into the language in the same way that Perl's regex system is.  Sure, you can do all the same things with Python, but it's not always as clean or as simple.

Each is good for their own thing, but OO is not one of Perl's strengths.

Jedidiah.

[ Parent ]

Regex as object ... yuck! (none / 0) (#130)
by ConsoleCowboy on Thu Apr 01, 2004 at 02:22:02 PM EST

Which is not to say you can't do everything in Perl that you can do in Python - it just isn't always quite as clean and easy. Likewise, Python has a very nice regex engine, but it just isn't merged into the language in the same way that Perl's regex system is. Sure, you can do all the same things with Python, but it's not always as clean or as simple.

I do not understand why Python implemented regex as object. Same for PHP wrt to making regex functions. It make so much more sense to have them as operator. Maybe my Perl background is percolating, but this is one the most annoying thing when I program in Python or PHP IMHO.


:wq
[ Parent ]
bla (2.81 / 11) (#73)
by spakatak on Wed Mar 24, 2004 at 01:18:19 AM EST

Perl is to OO what Dr. Frankenstein is to Cosmetic Surgery. PHP isn't much better.

My summary of the three P's is as follows:

Perl is for string manipulation. Nothing else is in the same league, yet alone the same ballpark.

Python is for high level OO design. It whips the other P's in that department.

PHP is for quick and dirty web applications. It doesn't scale well to large applications, but I'll be damned if you can whip up a simple content management system in under 5 minutes in anything else.

The three are not mutually exclusive. Of those three, I prefer python. However I use the right tool for the job.

to throw a few more languages onto the heap.

C: When all you have is a hammer, everything looks like a nail. Make a tiny mistake and you hit yourself in the thumb. Hard. and it hurts.

C++: Swiss army hammer.

Java: Someone took a C++ Hammer and added a motorized head to make it simpler to use. A thick layer of padding was added to protect the user from hurting themselves when they banged their thumb, but this makes it difficult to hammer nails into anything harder than balsa.

C#: Someone spray painted the Java hammer to make it look different. They then added a new mechanical head and a thinner layer of padding to make it work better, but the Java people still think theirs is better because someone else told them it can hammer in more nails per second than C.

Haskell: You specify you want the nail in the wood, and the hammer works out how to do it.

ASM: You have to push the hammer into the wood with your bare hands

VB: You buy the wood with the nails already in it.

Delphi: You bang the wood against the nail.

SQL: You tell it which wood and which nails you want. The interpreter then finds and joins them

Ruby: Someone took frankenstein (perl) and smoothed over the scars with the hammer.

[ Parent ]

PHP scalability (none / 1) (#129)
by ConsoleCowboy on Thu Apr 01, 2004 at 02:15:34 PM EST

PHP is for quick and dirty web applications. It doesn't scale well to large applications, but I'll be damned if you can whip up a simple content management system in under 5 minutes in anything else.

Horde/IMP seem to contradict you on the subject. I am running it for 82K accounts, and so far it is doing great. And this is a very large application. I think you will have to revisit PHP some day.


:wq
[ Parent ]
You seem to forget... (none / 0) (#88)
by DDS3 on Wed Mar 24, 2004 at 10:49:38 AM EST

...that perl is pretty crappy.  OO-perl is even worse.  If you wanna use OO, then Python is excellent.

Perl is EXCELLENT for filters, tiny applications, and string heavy report generators.  Aside from that, perl should be avoided.  In other words, perl is not and should not be used as a generalized programming language.  It works very well for what it was designed to be, which is exactly what I've stated.  After which, use a better tool.  Python and Java are both good generalized tools.  This is in spite of the fact that I hate Java and love Python, C, and C++.  And yes, I've done a heck of a lot of perl code too.  Simple fact is, I'm a better person for having moved beyond perl as a general programming langage.

So, while I respect your right to do your sites in Perl, I've never seen any sizable perl application that didn't need to be burned and done better in a generalized programming language.  Which is not to say, I doubt it can be done, I'm just saying, it surely is going to be very rare to find.

[ Parent ]

Cookie-cutter Perl bashing (none / 0) (#128)
by ConsoleCowboy on Thu Apr 01, 2004 at 02:04:57 PM EST

Perl is EXCELLENT for filters, tiny applications, and string heavy report generators. Aside from that, perl should be avoided. In other words, perl is not and should not be used as a generalized programming language. It works very well for what it was designed to be, which is exactly what I've stated. After which, use a better tool. Python and Java are both good generalized tools. This is in spite of the fact that I hate Java and love Python, C, and C++. And yes, I've done a heck of a lot of perl code too. Simple fact is, I'm a better person for having moved beyond perl as a general programming langage.

I hear that all the time, the usual unsubstantiate rant about how Perl is bad, weak, only good for text filtering, etc. Would you care to back up your point and tell us exactly where and how Perl fall short ?


:wq
[ Parent ]
Inaccurate maligning of PHP (none / 0) (#127)
by smagruder on Wed Mar 31, 2004 at 03:12:02 PM EST

PHP 5 is all about turning PHP into Java, while still managing the model of code directly in web pages. I know that PHP supports templating systems and all, but it doesn't seem to be the focus of the developer community to write that kind of code.

I'll grant you that PHP isn't often being utilized for its OO potential, but to say that templating isn't the focus of the serious developer community is stretching matters. Look at phpBB, which is in my estimation has a very large development community involving myriad mod developers. phpBB is heavily templated.

Further, .php's don't necessarily have to correspond to pages. You can indeed have .php's with functions or classes _only_ that are reused from various .php pages.

Steve Magruder
True Democracy = True Freedom
[ Parent ]

Further... (none / 0) (#131)
by smagruder on Thu Apr 01, 2004 at 02:35:00 PM EST

I also intended to say that you can have a .php page be entirely PHP code, rather than a mixture of HTML and PHP. On top of that, that "page" can generate different HTML views depending upon parameters passed in. So, the idea that PHP only provides for embedding code into web pages doesn't play out in the real world of its usage.

Steve Magruder
True Democracy = True Freedom
[ Parent ]

Java Implementation (none / 3) (#68)
by spakatak on Wed Mar 24, 2004 at 12:04:02 AM EST

While I'm thinking of it, I've started writing a Java application server "Inspired" by Zope in my spare time. It uses a persistant object store and a java implementation of Zope Page Templates. So far it works quite well. Development is very simple, it's completely compatible with existing Java code, and handles a few hundred requests per second on a test page (A simple Forum). If anyones interested in helping me develop it, let me know. I'll probably stick it up on Sourceforge under the GPL when I get round to it.

Thats illegal (1.10 / 10) (#71)
by foon on Wed Mar 24, 2004 at 12:52:55 AM EST

I'll probably stick it up on Sourceforge under the GPL when I get round to it. Unless your program is only used with the inferior theftware Java implementations, you are inevitably going to run up the viral provisions of the GPL if you attempt to do this. If your software requires linking against the Java libraries (and it is pretty much impossible to write a Java program that doesn't ), and it is run using the sun Java virtual machine, the act of executing your software will produce a derived work consisting of both GPL-incompatible code (namely, the Java library) and GPL code, and hence using it will be against the GPL, in much the same way that using the Qt libraries distributed under Trolltech's highly reasonable licensing terms along with GPL software was illegal before they caved into pressure from "open source" activists. A better choice would be to keep the code proprietary and distribute binaries as freeware if you are dead-set against deriving any kind of profit from the making of computer software.

[ Parent ]
or use a license .... (none / 1) (#72)
by horny smurf on Wed Mar 24, 2004 at 12:57:46 AM EST

... that doesn't try to make a political statement.

[ Parent ]
Compiler (none / 1) (#77)
by ensignyu on Wed Mar 24, 2004 at 04:25:22 AM EST

IANAL, but I think you're allowed to link to system/compiler libraries without violating the GPL. There's a lot of GPL'd Java applications out there.

[ Parent ]
Err... (none / 2) (#78)
by Alannon on Wed Mar 24, 2004 at 04:32:25 AM EST

You seem to not understand the GPL particularly well.  GPL has absolutely nothing, 0, nada to say about how you can use the software, except that it is not warranted in any way.  While you MIGHT be correct that running the program might be considered a derived work (the GPL doesn't say anything about that either, and a court has never decided one way or another), unless you were to DISTRIBUTE that 'derived' product to somebody else, you are not breaking the GPL.  Of course, it should be obvious that the GPL and Java are not incompatible, considering the huge library of GPL software for Java available.

[ Parent ]
The FSF disagrees (none / 0) (#96)
by foon on Wed Mar 24, 2004 at 02:33:36 PM EST

From the GPL FAQ:

Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL--if you can't, or won't, do that, you may not combine them.

What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.


Clearly, dynamic linking does create a derived work according to the GPL. And there is a long tradition of the FSF going after cases of GPL software linked to non-GPL libraries. As I mentioned, the whole Qt controversy was exactly that (KDE contains no code copied straight of Qt and doesn't statically link to it). So is the whining fit they are having over the new X Windows license, which is only a problem because of GPL software linking against X libraries. And the argument that Java is part of the "operating system" is ridiculous; it is a standalone user-space application.

The bottom line is that if you use the GPL, you are implicitly supporting the FSF's program of abolishing commercial software and requiring all source to be released under the GPL. If you use the GPL with software that dynamically links to commercial software, you are deliberately making your software illegal to use unless you modify the license (but the modified license is itself GPL-incompatible, so doing this is pointless). Anyone who wants to avoid these issues should stick to the proven proprietary software model or use a non-viral license.

[ Parent ]
Linking (none / 0) (#92)
by Sloppy on Wed Mar 24, 2004 at 12:08:03 PM EST

If your software requires linking against the Java libraries (and it is pretty much impossible to write a Java program that doesn't ), and it is run using the sun Java virtual machine, the act of executing your software will produce a derived work consisting of both GPL-incompatible code (namely, the Java library)
Just because some GPL zealots say that linking produces a derived work, doesn't make it true. Just don't static-link (and I don't think Java dudes do that anyway). Let the user worry about installing the JVM and Java library, instead of shipping it yourself, and your program will not be a derived work of Sun's stuff.
"RSA, 2048, seeks sexy young entropic lover, for several clock cycles of prime passion..."
[ Parent ]
in fairness to PHP/Perl devs (none / 1) (#76)
by salimfadhley on Wed Mar 24, 2004 at 03:38:58 AM EST

Nobody ever embeds PHP code into html once you get beyond the basics of scripting. Just because something is really easy to do does not mean you should do it right?

The ability to embed code is fine for very tiny projects that you know will never need to expand, but I wouldnt want to give the impression that this is something all php and mod_perl people do all the time!

Java is superior (none / 0) (#79)
by boxed on Wed Mar 24, 2004 at 05:56:44 AM EST

Java servlets solves this problem nicely. Webwork1.4+jsp (or velocity or freemarker if you don't like JSP), and maybe sitemesh and you have a very flexible fast system that is a breeze to work with. Plus you get the entire java class library and you run on any servlet container.

Java is good but not "superior" (none / 0) (#89)
by joib on Wed Mar 24, 2004 at 11:17:12 AM EST

The really good thing about Java is that there are lots of REALLY good open source libraries and frameworks. Hibernate for example is a truly magnificient OR mapper. The spring framework provides lots of very useful stuff in a very easy to use package.

OTOH, what I don't like about Java is that developing with it is so slow. The syntax is overly verbose, especially compared to python. The need to compile your classes before you can test them makes the whole process even slower. ant, while very useful, is no speed daemon either. Not to mention tomcat. Why the #"$%! does it take 45 seconds for tomcat to start? OTOH, I've heard that weblogic can take up to 5 minutes to start! And when doing JSP pages, you'll quickly get mad at the speed of the jsp compiler (or rather, the lack of speed) But why? I mean, every non-Java server starts in a few seconds. And as a language, Java is not especially slow. It surely is way faster than python, perl or php, and in many tests it even comes close to C/C++. Perhaps the servlet containers are just over-engineered with lots of useless baggage.

[ Parent ]

Groovy (none / 1) (#113)
by kellan on Thu Mar 25, 2004 at 02:56:05 PM EST

Venturing pretty far off topic now, but I've just started playing with Groovy, and it nicely solves the overly verbose Java syntax problem, without giving up access to the wonderful Java libraries.

Ted Leung has some slides (pdf) from a recent SeaJUG talk.

[ Parent ]

hah! (none / 0) (#114)
by boxed on Thu Mar 25, 2004 at 04:59:37 PM EST

You can make a totally incompetent implementation of anything in any language. Tomcat and Weblogic are such systems. Look at resin and orion, they both start up in as you say "a few seconds", they compile JSP pages in a fraction of the time (you hardly notice the recompile ever takes place most of the time!), faster, takes less ram etc etc.

[ Parent ]
Tuples (none / 0) (#102)
by spakatak on Wed Mar 24, 2004 at 07:24:13 PM EST

Theres one thing I'd kill for in Java- Tuples. Once you've used them, it becomes a pain in the arse when you have to go back to a more traditional language. List comprehension would also be nice.

[ Parent ]
I like Zope, but the documentation isn't yet there (none / 1) (#80)
by izogi on Wed Mar 24, 2004 at 06:02:35 AM EST

I've tried to learn Zope a couple of times, the latter a very serious attempt. It's a really neat and somewhat original framework for doing web development.

What caused me to give up, though, was the lack of useful online documentation that was available about a year ago. Almost none of it was actually up-to-date. The Zope Book itself was focusing on promoting the zope scripting language instead of their recent replacement, page templates. It also lacked any really useful examples for situations that might have seemed realistic.

The available documentation of the provided class libraries, both from the Zope help interface and on the web, was very brief and lacking useful substance at best... assuming there was any at all for any particular class. Even figuring out how to design a simple username and password login box that would interact with Zope's internal user management system (to replace the Zope-native popup alert box) took me several weeks on and off to figure out, and included excessive reading through the Zope source code. The information required about how to do it simply wasn't documented in any place that I could find.

Most of the other online documentation consisted of amateur howto-type documents, which were badly indexed and hard to search, usually of dubious editorial quality and frequently very out of date. There wasn't a system in place to remove older such documents, or even categorise them into an older section.

Zope looks like a very interesting way to arrange a web framework, and I hope it eventually gets properly recognised for this. But the place that was most frustrating and ultimately caused me to give up was the frustration and difficulty in figuring out how to do what should really have been very simple things.


- izogi


I use Zope since it's 2.2.x versions (none / 0) (#83)
by burbilog on Wed Mar 24, 2004 at 07:33:16 AM EST

I use Zope since it's 2.2.x versions for our corporate sites and I find it quite useful. BUT. It's buggy as hell. It saves my time, but tracking problems is very difficult :(

-- If the life is just a game of D&D then the DM really sucks.
hmm (none / 0) (#85)
by spakatak on Wed Mar 24, 2004 at 08:55:39 AM EST

I use 2.6.2. Rock solid.

[ Parent ]
Try it for free (none / 0) (#84)
by jschwarz on Wed Mar 24, 2004 at 07:49:21 AM EST

http://www.freezope.com/

Problems (none / 3) (#90)
by AWhiteStar on Wed Mar 24, 2004 at 11:36:06 AM EST

I spent two years developing a fairly large system in Zope as one of five developers.

At first, I was very impressed with the flexibility and the easy implementation of simple tasks. When using it for a while, however, I learned to hate it.

  1. The Zope source code is horribly written and documented. When you look into it, you are going to find lots of undocumented functions and variables called "a" or "st".
  2. The manual sucks big time. The tutorials barely cover the most important functions, there are no cross-references, and it is seriously lacking useful examples.
  3. Debugging is a real pain. The only IDE I know of which supports the debugging of Zope Products is "WingIDE", which is lacking a lot of other important features, and the debugging of Page Templates is still not possible.
  4. The naming conventions are horrible. There is a different syntax for the "self" object in every language you have to use, for example: External Methods, Products, ZPTs and DTML: "self", "this", and "here".
  5. While the Page Template approach of writing code which looks good in every HTML editor is nice in theory, this produces a lot of redundant code in practice. The HTML pages are often riddled with "<span>" statements.
  6. While there is a debug mode, is it not possible to write the error log to the HTML page you are just viewing, you only see a generic error message. This is very annoying if you are debugging ZPTs.
  7. The debug mode is very slow. Even simple tasks on a fast machine take too long.
I like Python and think Zope is a good idea, but for a real large project I would use something different in the future.

Current Zope user, moving away from it (3.00 / 10) (#91)
by malraux on Wed Mar 24, 2004 at 11:47:11 AM EST

Caveat: I'm using an older version (2.3.3) of Zope for a medium sized site (300-500K hits/month). Many of these complaints may well have been fixed (and judging from a few of the comments here, they have been). Don't bother responding just to call me an idiot if this stuff has been fixed. Read #4 instead.
  1. Repository development is ass. WebDAV and remote FTP do not fix this, and the Zope admin interface is good for only small on-the-spot changes. I saw the comments above about how this isn't true any longer; I'd like to see details on that.
  2. There's a pretty severe adversarial relationship between ZODB development and RDBMS development. Zope wants you to drink the Kool-Aid. Yes, Zope SQL methods are Nifty. In the long run, however, they're more trouble than a simple Spring Framework JDBC method.
  3. Python scripts calling DTML document/methods is wonky. There were way too many things I had to work around to get things working. The whole experience felt like one giant hack. "Well, Zope does things like this, so to do what you want to do you have to do this, this, and this, as well as this, but that's broken, so do it this way."
  4. Upgrades are hell. If you buy into the "Zope Products make things EASY!" mantra, you'll run into issues with incompatibilities when it's time to upgrade. See #1 above as well.
  5. Broken Postgres drivers. My site (z.iwethey.org/forums) has to run in single user mode or the Postgres drivers lock up (and no, it's not deadlocks).
  6. Acquisition isn't all it's cracked up to be. Lots of things just don't work as expected, resulting in odd work-arounds. Could be an understanding issue, but if that's the case then it fails the 15 minute rule.
  7. Strange bugs in the Products. The ODB grows and grows, even though all of the volatile data is in Postgres. I suspect that something with either exUserFolder or Formulator is causing transactions to occur for no reason.
  8. exUserFolder in particular is a pain in my ass due to its ultra-aggressive caching. A database adapter should look at the database occasionally, folks. As it is, changes to user information in the database are NEVER read by exUserFolder after the initial load, and there doesn't seem to be any way to flush the cache. As a result, I can't change a user's password manually.
  9. Repositories are ass, Part Deux: a few days ago, due to the growing ODB problem (#7), the ODB went on a feeding binge and hit 2G (packed, it's 7.5M). Not a problem on Reiser, you wouldn't think... except that we are still using Python 1.5.2 for various library reasons (see #4). This Python has 2G compiled in as a hard limit for file sizes, resulting in a corrupted ODB. Due to various reasons, we had to revert to an older copy of the ODB (a few months ago) to restore. Because of #8, many users lost changed user preferences that were being cached in the old copy of the ODB.
  10. DTML is ass, too. :-) I haven't looked at ZPT yet to see what it's like.
All in all, the initial experience was great: I put together a very nice, functional site in about 20 hours of initial effort. The maintenance is hell, though.

My conclusion is that Zope is great for prototyping, but I don't intend on continuing with it. To repeat my caveat above, however, I'm on an old version, so check to see if these problems still exist.

Regards,
-scott

Administrator of zIWETHEY forums

Fixed (none / 0) (#100)
by spakatak on Wed Mar 24, 2004 at 07:20:26 PM EST

Pretty much everything there has been fixed.

[ Parent ]
Fixed (none / 0) (#101)
by spakatak on Wed Mar 24, 2004 at 07:23:26 PM EST

Pretty much everything there has been fixed.

[ Parent ]
Please elaborate. (none / 0) (#106)
by Another Scott on Wed Mar 24, 2004 at 08:02:02 PM EST

"Pretty much everything" isn't terribly descriptive. Please elaborate, addressing malraux's concerns if possible.

Thanks.

Cheers,
Scott.

[ Parent ]

Ok (none / 2) (#108)
by spakatak on Wed Mar 24, 2004 at 08:33:54 PM EST

Repository development is ass. WebDAV and remote FTP do not fix this, and the Zope admin interface is good for only small on-the-spot changes.

You put content in the ZODB, and code on the filesystem. You edit such code as you would anything else. The WebDAV/FTP issue still exists for content in the ZODB, but you can stick it on the filesystem if you so choose. (In general a PHP solution would store content in a database anyway, which is even harder to manage)

There's a pretty severe adversarial relationship between ZODB development and RDBMS development.

the ZODB is not a replacement for an RDBMS. you use the right tool for the job. The old analogy of "When all you have is a hammer, everything looks like a nail" applys here. I can't really explain why you should use the ZODB if all you understand is SQL. You have to try it, and sometimes it takes a while to click.

Python scripts calling DTML document/methods is wonky. There were way too many things I had to work around to get things working. The whole experience felt like one giant hack.

DTML sucks, nobody is contesting that. It was Zopes biggest mistake. I'm not sure what issues you had with them and python scripts, but It all works fine and dandy for me nowadays.

In any case, if your writing anything remotely complex make a product. It's not as hard as it looks.

Broken Postgres drivers.
I can't comment on this as I don't use them. the MySQL and ODBC adapters work for me.

Acquisition isn't all it's cracked up to be. Lots of things just don't work as expected, resulting in odd work-arounds. Could be an understanding issue, but if that's the case then it fails the 15 minute rule.

Acquisition is one of Zopes most powerful features, but it does stump a lot of people. It's a lot simpler than it seems at first, so stick with it and it'll click. Once you get used to it you'll wonder how you ever worked without it.

Strange bugs in the Products. The ODB grows and grows, even though all of the volatile data is in Postgres. I suspect that something with either exUserFolder or Formulator is causing transactions to occur for no reason.

Can't comment on exUserFolder. the ZODB grows because it stores undo information. I believe many RDBMS do this as well. I have never had a problem of a ZODB growing very quickly- I usually pack it every few months.

exUserFolder in particular is a pain in my ass due to its ultra-aggressive caching.

Again, I don't use it but every other product I've used that uses a RDBMS has an option for changing the level of caching or turning it off completely

This Python has 2G compiled in as a hard limit for file sizes, resulting in a corrupted ODB. Due to various reasons, we had to revert to an older copy of the ODB (a few months ago) to restore.

You were using an aincent copy of Python. Enough said. Python 2 doesn't have this problem. (I've had several zope servers running for ~2 years and never had a corrupt database).

DTML is ass, too. :-) I haven't looked at ZPT yet to see what it's like.

Yep. DTML Sucks. ZPT, however, is brilliant. You will have to get out of the PHP habit of mixing the presentation and logic layers.

[ Parent ]

Ok (none / 1) (#109)
by malraux on Wed Mar 24, 2004 at 09:06:48 PM EST

You put content in the ZODB, and code on the filesystem. You edit such code as you would anything else. The WebDAV/FTP issue still exists for content in the ZODB, but you can stick it on the filesystem if you so choose. (In general a PHP solution would store content in a database anyway, which is even harder to manage)

Code, as in just Plain Old Python? Do you still have to restart the Zope server to see the changes?

the ZODB is not a replacement for an RDBMS. you use the right tool for the job. The old analogy of "When all you have is a hammer, everything looks like a nail" applys here. I can't really explain why you should use the ZODB if all you understand is SQL. You have to try it, and sometimes it takes a while to click.

I didn't say it was a replacement. I said that the RDBMS support in Zope is at odds with how the ODB stuff wants to be done. When I started using Zope (again, I freely admit it's changed) there wasn't even indexing for the ODB. A good example is modeling a hierarchical RDBMS structure in the ODB, or in using such a structure in the ODB.

DTML sucks, nobody is contesting that. It was Zopes biggest mistake. I'm not sure what issues you had with them and python scripts, but It all works fine and dandy for me nowadays.

Figuring out how to call a particular object (like a SQL method or the like) from a Python script is difficult at best. Usually this results in playing around until I find just the right magic incantation for the script to be able to find the other object/method.

Acquisition is one of Zopes most powerful features, but it does stump a lot of people. It's a lot simpler than it seems at first, so stick with it and it'll click. Once you get used to it you'll wonder how you ever worked without it.

That's what people always say. I'm pretty sure I know how it works. It just doesn't always work as it ought to in every situation. I'd have to go dig through the code to find an example, but there are a couple of places in my app where acquisition was much more of a hindrance than a help.

Can't comment on exUserFolder. the ZODB grows because it stores undo information. I believe many RDBMS do this as well. I have never had a problem of a ZODB growing very quickly- I usually pack it every few months.

I shouldn't have to pack it at all if I'm not changing objects or code. The Postgres database is the only volatile portion, yet the ODB insists on transactioning something, growing several megs per day.

Yep. DTML Sucks. ZPT, however, is brilliant. You will have to get out of the PHP habit of mixing the presentation and logic layers.

I was never IN that habit, which is why I said DTML is ass. ;-)

Thanks for the response.


Regards,
-scott

Administrator of zIWETHEY forums
[ Parent ]

ok (none / 0) (#110)
by spakatak on Wed Mar 24, 2004 at 09:43:35 PM EST

Code, as in just Plain Old Python? Do you still have to restart the Zope server to see the changes?

Using the management interface you can refresh an indivual product with the click of a button. It's virtually instant.

I didn't say it was a replacement. I said that the RDBMS support in Zope is at odds with how the ODB stuff wants to be done. When I started using Zope (again, I freely admit it's changed) there wasn't even indexing for the ODB. A good example is modeling a hierarchical RDBMS structure in the ODB, or in using such a structure in the ODB.

I've only used RDBMS stuff in zope a few times, and it's worked pretty well. Zope has changed a lot since 2.3, so try 2.7.

As for modeling a RDBMS structure in the ODB- this is a bad iea. If your storing relational data put it in a relational database. I minicked an RDBMS structure for a sales system I developped and it worked quite well, but in hindsite a relational database would have been a better choice.
Figuring out how to call a particular object (like a SQL method or the like) from a Python script is difficult at best. Usually this results in playing around until I find just the right magic incantation for the script to be able to find the other object/method

I can't comment on Zope 2.3, but in 2.5 and up (what I've used) you simply call it as you would any object. if it's called "foo" and it's in the current context (or aquisition can find it) just call context.foo(). If you need to pass parameters then just pass them (context.foo('test','ing'))

I shouldn't have to pack it at all if I'm not changing objects or code. The Postgres database is the only volatile portion, yet the ODB insists on transactioning something, growing several megs per day.

I guess there must have been a bug somewhere causing this. I havn't seen this happen in 2.5+, so it's likely that it's been fixed.

I was never IN that habit, which is why I said DTML is ass. ;-)

:p. DTML tried to be a procedural language with an XML syntax, and does it badly. It goes against every good design principle known to man.

Use Python Scripts (or a product) for processing and a Page Template to format and display the finished data. It's roughly anagolous to the Java system of JSP = presentation, Servlets = processing.

That's what people always say. I'm pretty sure I know how it works. It just doesn't always work as it ought to in every situation. I'd have to go dig through the code to find an example, but there are a couple of places in my app where acquisition was much more of a hindrance than a help.

To enable aquisition on your objects you inherit from the Aquisition.Implicit base class. If you don't do that, your object bahaves as it would in Java or PHP. If you are having trouble understanding Aquisition then don't use it.

That said, it really isn't that complex. Read the chapter in the Zope Book on Aquisition and it should shed some light. If you have any specific problems let me know and I'll try and shed some light.

[ Parent ]

I am looking for a new development environment (none / 0) (#133)
by Orion Blastar on Sun Jun 06, 2004 at 08:40:48 PM EST

I was going to use PHP or Zope. I was exposed to Zope while using your forums. I downloaded the source to your forums and see that you are doing a PHP migration.

My skills are in ASP programming and VBScript. I just migrated everything except an ASP forum to Linux and Apache. I know a bit about PHP 3.0, but haven't touched PHP in quite a while and my skills are already outdated.

I've currently looked into Mono and the ASP.NET mod, it does not yet look ready for prime-time.

I have to say no to job offers because they want ASP.NET experience of at least two years.

If possible, after I graduate college and have nothing else to do, I could help you migrate or make modifications to your forum software as I learn a new platform. My way of trying to pay you back for all the trouble I've caused you. That is if you want my help. If not, I'll just look into another forum software and see what I can do.

For some reason the author of this story forgot technology like JSP, CFM, ASP, or even Perl scripting.

My experience has been mostly Intranet legal applications, but I think I can adapt my skills to a forum, pretty much I did legal content management for lawyers and legal aides to use.
*** Anonymized by intolerant editors at K5 and also IWETHEY who are biased against the mentally ill ***
[ Parent ]

Zope rocks (none / 2) (#99)
by shapr on Wed Mar 24, 2004 at 04:41:47 PM EST

I've been making a living building very complex websites with Zope and now Plone over the last two years or so, it's the best thing going.

I used J2EE for several websites, but much prefer Zope.

I agree, Zope is large, and it's complex. In my opinion, it's large and complex because it has so much functionality.

If you get as far as Plone and Archetypes, you reach a level of Object Publishing rather than scripting or building 'web pages'. The objects you publish can be multilingual, are automatically catalogued, can have their own finite state machines attached to them to give a user submit / editor publish process, and lots more.

It's great stuff, I believe it's both more powerful and simpler than J2EE, and that it's much less fragmented than PHP.
I still wish it were easier to upgrade Zope and the various plugins, and that more unit tests were included in the various plugins, but from what I've seen and for what I do, Zope is the best choice.

Zope Sux (none / 2) (#104)
by A55M0NKEY on Wed Mar 24, 2004 at 07:44:00 PM EST

Just my opinion after playing with it for a while.

Whoa, Too .... Much ... Negative .... Energy (none / 1) (#112)
by libertaduno on Thu Mar 25, 2004 at 11:26:45 AM EST

I use zope all day almost everyday for a lot of stuff and i have not found it to be excessively buggy or poorly-documented all (it was in the past). Zope rocks. Zope makes it easy to get things done. Zope for Content Management (see plone.org) is especially good. Clustering is easy and powerful. Zope is not particularly slow, but of course that is relative and depends on what you are comparing it to.

Zope is hard to get started with yes, but there is a payoff for the initial learning curve. Zope can also be bloated at times, yes and that can be a real PITA. But it has its advantages. Its getting better tho, eg a default Zope 2.7 install uses maybe 20M RAM out of the box.

Debugging zope can be a pain at times but what advanced application server isn't a pain to debug?

A lot of the criticisms of Zope posted here are somewhat outdated I think...

disclaimer: I have business that involves zope. (of course i wouldn't be involved in such a thing if i didn't think zope was excellent.)

Truth is never bad. -- Ernesto Guevara

eZ publish (none / 0) (#117)
by hovik on Fri Mar 26, 2004 at 06:05:44 AM EST

Hi

Before ditching PHP you should take a look at eZ publish. It's based on PHP and is DB independent. ( PostgreSQL and MySQL supported out of the box ).

I find it a lot more intuitive to use and more out of the box ready than Zope.

A very flexible template language, easy creation of modules and very powerfull extension system makes it very easy to use on customer projects.

eZ publish vs Zope (none / 0) (#121)
by salimfadhley on Fri Mar 26, 2004 at 07:28:11 PM EST

eZ looks like a professionally written content management system.

You could build something *like* eZ publish in Zope (or Perl, or mod_python), but you couldnt build something like zope in eZ publish.

Zope is NOT a content management system!

:-)

[ Parent ]

Other tools (none / 0) (#120)
by ajs on Fri Mar 26, 2004 at 02:17:13 PM EST

I've heard both good and bad about Zope, but at least it's a framework. I'm always glad to see a high-level generic tool rather than something which only has a single purpose in life.

Then again, the single-purpose tools have wide adoption too, and often solve their specific problems more completely.

Other frameworks include:

Generic contenet management frameworks:

* bricolage (Perl/Mason)
* struts (Java)
* openinteract (Perl/TTK)

Lower-level templating systems (the above are often build upon these)

* PHP (PHP)
* TTK - Template Toolkit (Perl)
* Mason (Perl)
* JSP (Java)

Application-specific content managers:

* Slashcode (Template Toolkit) - Weblogs
* Postnuke (PHP) - Weblogs
* phpBB (PHP) - Forums

and many, many more of course.

-- Aaron Sherman <ajs@ajs.com>

struts != CMS (none / 0) (#124)
by kellan on Tue Mar 30, 2004 at 09:48:31 PM EST

Not sure how you're defining "content management framework", but Struts just doesn't have any content management built in.

Conversely Mason does have a tightly linked CMS framework.

But your basic point stands.

[ Parent ]

eZpublish Right to Reply (none / 1) (#123)
by salimfadhley on Tue Mar 30, 2004 at 12:08:27 PM EST

Andre (an eZpublish developer) says that some of my comments are incorrect, so since new users cannot sign up for K5 accounts (grumble, grumble, death of K5 etc), I have paraphrased and posted his words here.

In my to me describing eZpublish as something that looks like a CMS, Andre observes the following:

"eZpublish, it became much more of a general framework since at v3.x - eZpublish is now a professionally written generic web application framework much like Zope

Incidentally, using it as a CMS is just the way it began, years ago. The CMS application is built on top of the framework.



What I Learned (none / 0) (#132)
by czolgosz on Fri Apr 02, 2004 at 01:33:02 AM EST

I started using Zope three years ago, for a small app. I liked the Python scripting, despite its sandbox restrictions, but found DTML vexing.

Since then I dabbled from time to time.

I recently had a need for another little web app, and built it in Zope. ZPT is a thing of beauty, one of the nicest templating implementations I've seen. The Python scripting is still there. The only thing that bothers me about it is that, at least to me, Zope is kind of opaque, which leads to a steep learning curve. The API isn't exactly orthogonal, and the calling interface between Python scripts and page templates still confuses me slightly. I've heard gripes about ZODB scalability, but for the kind of things I'm doing, that shoe has never pinched.

I agree with other posters who found debugging to be far from straightforward. I ended up writing some little unit test methods with "return printed" at the end; a far from ideal situation but not as clunky as I feared it would be.

On the whole I've found Zope worthwhile, but not a liberating experience to the same degree that (say) learning Python was. I'd use it again for GUI prototyping, little one-off apps, things like that. I'm not sure how big I'd be willing to scale it. For a lot of corporate intranet web apps, I think it'd be a good choice.


Why should I let the toad work squat on my life? --Larkin
Switching from PHP to Zope/Python | 133 comments (86 topical, 47 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!