Slashdot Mirror

We use Zope a lot where I work, so we have ALL the books. The Zope Bible (mentioned by GeorgeH above) is my favorite. However, most printed books make heavy use of the semi-deprecated DTML tags, rather than the more "strategic" ZPT tags, an approach which made sense back when they were written, but not now.

And there is still no introductory documentation on Zope CMF: not even on a web page, anywhere, no, not even on the Zope CMF site. They do have some nice outlines of what needs to be written, along with some vain pleas in the comments for it to actually get done sometime. When will it actually BE written? What is CMF? What do you use it for? What do all its components do, in a nutshell, and why and when should you use them? Zip. To understand that, you'll need to delve into the source and fsck around with it 'til it makes sense. Zope was intended to be a Web CMS for web developers, not for Python hackers. We're a little afraid for its future now, especially now that Guido is moving on.

Jesterzog is right: its doesn't matter how good Zope is, if mere mortals can't use it.

I'd really like to write some CMF documentation myself, now that I finally understand it. But I'm doing 2.5 jobs at the moment, and every day wears me out. Maybe when my team's current project finishes I can persuade my boss' boss to let me have a little time to do this, to protect our heavy time investment in Zope and CMF.

I was experimenting with Zope last year and again during the first half of this year. It's definitely a cool product, but what threw me for now at least was that the documentation is abysmal, at least online.

From what I've been able to tell, there are several editions of the Zope book -- the only up-to-date version of which (currently 2.6) is still work in progress. The rest of the documentation is a mish-mash of user-written howto's, some of which are excellent, some of which are dupes of others, many of which are out of date, and others of which are just badly written. Searching the database of these is hard, and it's very difficult to distinguish well written old ones that are still relevant from newer ones that aren't very useful.

My main problem with it though is that although it focuses hugely on the differences between zope development and regular web development without seriously dealing with implementation examples of common tasks. On and off it took me about a month to figure out how to make a simple form-based login system (similar to slashdot's) and tie it into Zope's user folder system. Co-incidentally The only zope-based website I could find that actually did this was zope.org itself.

I really like Zope and I've shown off how it works to people many times over. But I'll only seriously consider using it more once the documentation is more coherent. At the moment I think that's one of the main places where itfalls over.

I was experimenting with Zope last year and again during the first half of this year. It's definitely a cool product, but what threw me for now at least was that the documentation is abysmal, at least online.

From what I've been able to tell, there are several editions of the Zope book -- the only up-to-date version of which (currently 2.6) is still work in progress. The rest of the documentation is a mish-mash of user-written howto's, some of which are excellent, some of which are dupes of others, many of which are out of date, and others of which are just badly written. Searching the database of these is hard, and it's very difficult to distinguish well written old ones that are still relevant from newer ones that aren't very useful.

My main problem with it though is that although it focuses hugely on the differences between zope development and regular web development without seriously dealing with implementation examples of common tasks. On and off it took me about a month to figure out how to make a simple form-based login system (similar to slashdot's) and tie it into Zope's user folder system. Co-incidentally The only zope-based website I could find that actually did this was zope.org itself.

I really like Zope and I've shown off how it works to people many times over. But I'll only seriously consider using it more once the documentation is more coherent. At the moment I think that's one of the main places where itfalls over.

Other guys are mentioning many projects, but I want to emphsize on three project, IMHO the most important to illustrate the power of Python:

• Zope - IMHO the best ever written application server, thanks to laziness and OOP of Python;
• Plone - this portal is the best software written for Zope's CMF; Zope would stay popular only among hackers if there would be no Plone;
• Portage - the best ever written package management system; I doubt ebuilds and eclasses would be that flexible and power without Python;

Zope is a very cool web application system, and while I don't know of Guido's specific contributions I have to assume that they were great. Still, I'm confidant that Zope will carry on.

For those not familiar with Zope, it is a web application server written entirely in Python. It features an object database that, for example, lets you create an image object, and then call it from other code to automatically build your image tag based on the dimensions and title of the image stored in the object.

It's open source, developed both by the Zope community and the Zope corporation. There are at least two kick ass, open source content management systems built on top of Zope Corp's content management framework that I know of: Plone and Silva. There are a ton of add-on products that are downloadable too.

Zope does have a pretty steep learning curve, if you don't do stuff with "real" web applications (stuff that needs access control lists, user management, templating, etc) it might not be right for you, but it's great for bigger applications. Edd Dumbill talks in a recent blog entry about why Zope is worth learning and DevShed (which runs on Zope) has a good overview.

Guido and Dan Farmer are both smart guys and I'm sure that we can expect good things.

Zope is a very cool web application system, and while I don't know of Guido's specific contributions I have to assume that they were great. Still, I'm confidant that Zope will carry on.

For those not familiar with Zope, it is a web application server written entirely in Python. It features an object database that, for example, lets you create an image object, and then call it from other code to automatically build your image tag based on the dimensions and title of the image stored in the object.

It's open source, developed both by the Zope community and the Zope corporation. There are at least two kick ass, open source content management systems built on top of Zope Corp's content management framework that I know of: Plone and Silva. There are a ton of add-on products that are downloadable too.

Zope does have a pretty steep learning curve, if you don't do stuff with "real" web applications (stuff that needs access control lists, user management, templating, etc) it might not be right for you, but it's great for bigger applications. Edd Dumbill talks in a recent blog entry about why Zope is worth learning and DevShed (which runs on Zope) has a good overview.

Guido and Dan Farmer are both smart guys and I'm sure that we can expect good things.

Zope is a very cool web application system, and while I don't know of Guido's specific contributions I have to assume that they were great. Still, I'm confidant that Zope will carry on.

For those not familiar with Zope, it is a web application server written entirely in Python. It features an object database that, for example, lets you create an image object, and then call it from other code to automatically build your image tag based on the dimensions and title of the image stored in the object.

It's open source, developed both by the Zope community and the Zope corporation. There are at least two kick ass, open source content management systems built on top of Zope Corp's content management framework that I know of: Plone and Silva. There are a ton of add-on products that are downloadable too.

Zope does have a pretty steep learning curve, if you don't do stuff with "real" web applications (stuff that needs access control lists, user management, templating, etc) it might not be right for you, but it's great for bigger applications. Edd Dumbill talks in a recent blog entry about why Zope is worth learning and DevShed (which runs on Zope) has a good overview.

Guido and Dan Farmer are both smart guys and I'm sure that we can expect good things.

http://mail.zope.org/pipermail/zope3-dev/2003-July /007598.html

Guido van Rossum guido@python.org
Wed, 09 Jul 2003 10:24:54 -0400

Dear Zope 3 developers,

Last night at OSCON I announced that I am moving to California. I
have accepted a new job at Elemental Security, a security software
startup in San Mateo. You may have heard of one of the founders, Dan
Farmer, who is the (co-)author of several well-known free security
checking programs: Satan, Titan and The Coroner's Toolkit.

Elemental is a brand new company, and I can't say much yet about the
product, except that it will be aimed at enterprise security and use
Python. I'm very excited about working with Dan on its design and
implementation.

I'm also excited about moving to California, which has long been a
dream of mine. I'm looking forward to getting together with the many
local Python users and developers once I'm settled; right now, my life
and that if my family is total chaos because we're trying to find a
home and move into it by August 1st.

I will still have time for Python (it's in my contract) and I will
continue to lead Python's development. The other PythonLabs folks:
Fred Drake, Jeremy Hylton, Barry Warsaw and Tim Peters, are staying at
Zope, by the way.

But unfortunately, this move pretty much ends my involvement in Zope
3. I've signed a contributors agreement, but with the new job and my
Python work I don't expect to have much time for Zope. So this is
also a goodbye, of sorts. I've enjoyed working with many of you, Zope
3 developers, and I expect we'll run into each other at some future
Python event.

In the mean time, I'm here at OSCON with a busy schedule and limited
access to my email, and the following weeks I will be in transition,
so please be kind if I don't reply immediate when you write me.

--Guido van Rossum (home page: http://www.python.org/~guido/)

PS. guido@zope.com no longer works. Please use guido@python.org!

You can read his goodbye posting to the zope3 list here

Also, Zope is not licensed under the GPL, but rather, a GPL-compatible license called the Zope Public License.

Zope!

I have a wild suggestion. If you want elegant, kludge-free web applications, drop PHP. The very nature of server-page based programming (PHP, ASP, JSP, etc.), the very act of mingling your code with your markup is non-elegant. Unfortunately, there really isn't any way of separating the two in an elegant fashion, so you're sorta destined for a kludge somewhere, but there are better ways.

One kludge I rather dislike about nearly all server-side programming is the necessity of a connection to a relational database. Invariably, you must get into a lower level to get your data; often you are forced to write SQL for your data, and if your database is complex your queries can get pretty convoluted. There are tools to try to make that transparent, but the cure is often just as bad as the disease.

There are better ways, however. Zope, a web application platform based on the Python programming language, is my current favorite. The big feature that I like best about Zope, aside from the excellent builtin security framework (which is head and sholders above PHP, BTW), is the persistent object database -- with it, Zope can entirely eliminate the necessity of an external database. Not that you can't connect to an external database if you really feel like it; Zope has a built in connectivity API, and there are plugins for all your favorite relational databases.

Zope has many elegant means of managing your content, from your standard header-footer includes to context-based acquisition, to the many content management frameworks already built for you on top of Zope like Plone. Zope comes with two powerful templating languages if you don't like straight Python: DTML and Page Templates.

That said, there are drawbacks: Zope is its own server, so you have to find a hosting company that offers Zope if you don't maintain your own servers. Zope.org lists a few free hosts on the main page. Using the object database is great, but because it's transactional your disk space can quickly bloat if you running a website whose data changes frequently, like, say, a popular forum or blog.

As for the language changes... if you left perl for php because perl was ugly (and believe me, I agree), then you should try python. The language is elegance personified. It's a scripting language, so it lacks the performance of Java or C++ for computation-oriented stuff, but the stuff it does, and the simplicity! Often I've seen three short lines of Python code take tens of lines of Java code to accomplish the same task. Python is so readable you rarely need to comment your code if your variable names are well named. It's also fully object oriented, but if you don't like OO for some odd reason, you can do your stuff with just functions.

Wow... what started off as just a few lines turned into a novel. Now I'm all tired and stuff. Can you tell I really like Zope and Python? :)

I have a wild suggestion. If you want elegant, kludge-free web applications, drop PHP. The very nature of server-page based programming (PHP, ASP, JSP, etc.), the very act of mingling your code with your markup is non-elegant. Unfortunately, there really isn't any way of separating the two in an elegant fashion, so you're sorta destined for a kludge somewhere, but there are better ways.

One kludge I rather dislike about nearly all server-side programming is the necessity of a connection to a relational database. Invariably, you must get into a lower level to get your data; often you are forced to write SQL for your data, and if your database is complex your queries can get pretty convoluted. There are tools to try to make that transparent, but the cure is often just as bad as the disease.

There are better ways, however. Zope, a web application platform based on the Python programming language, is my current favorite. The big feature that I like best about Zope, aside from the excellent builtin security framework (which is head and sholders above PHP, BTW), is the persistent object database -- with it, Zope can entirely eliminate the necessity of an external database. Not that you can't connect to an external database if you really feel like it; Zope has a built in connectivity API, and there are plugins for all your favorite relational databases.

Zope has many elegant means of managing your content, from your standard header-footer includes to context-based acquisition, to the many content management frameworks already built for you on top of Zope like Plone. Zope comes with two powerful templating languages if you don't like straight Python: DTML and Page Templates.

That said, there are drawbacks: Zope is its own server, so you have to find a hosting company that offers Zope if you don't maintain your own servers. Zope.org lists a few free hosts on the main page. Using the object database is great, but because it's transactional your disk space can quickly bloat if you running a website whose data changes frequently, like, say, a popular forum or blog.

As for the language changes... if you left perl for php because perl was ugly (and believe me, I agree), then you should try python. The language is elegance personified. It's a scripting language, so it lacks the performance of Java or C++ for computation-oriented stuff, but the stuff it does, and the simplicity! Often I've seen three short lines of Python code take tens of lines of Java code to accomplish the same task. Python is so readable you rarely need to comment your code if your variable names are well named. It's also fully object oriented, but if you don't like OO for some odd reason, you can do your stuff with just functions.

Wow... what started off as just a few lines turned into a novel. Now I'm all tired and stuff. Can you tell I really like Zope and Python? :)

I have a wild suggestion. If you want elegant, kludge-free web applications, drop PHP. The very nature of server-page based programming (PHP, ASP, JSP, etc.), the very act of mingling your code with your markup is non-elegant. Unfortunately, there really isn't any way of separating the two in an elegant fashion, so you're sorta destined for a kludge somewhere, but there are better ways.

One kludge I rather dislike about nearly all server-side programming is the necessity of a connection to a relational database. Invariably, you must get into a lower level to get your data; often you are forced to write SQL for your data, and if your database is complex your queries can get pretty convoluted. There are tools to try to make that transparent, but the cure is often just as bad as the disease.

There are better ways, however. Zope, a web application platform based on the Python programming language, is my current favorite. The big feature that I like best about Zope, aside from the excellent builtin security framework (which is head and sholders above PHP, BTW), is the persistent object database -- with it, Zope can entirely eliminate the necessity of an external database. Not that you can't connect to an external database if you really feel like it; Zope has a built in connectivity API, and there are plugins for all your favorite relational databases.

Zope has many elegant means of managing your content, from your standard header-footer includes to context-based acquisition, to the many content management frameworks already built for you on top of Zope like Plone. Zope comes with two powerful templating languages if you don't like straight Python: DTML and Page Templates.

That said, there are drawbacks: Zope is its own server, so you have to find a hosting company that offers Zope if you don't maintain your own servers. Zope.org lists a few free hosts on the main page. Using the object database is great, but because it's transactional your disk space can quickly bloat if you running a website whose data changes frequently, like, say, a popular forum or blog.

As for the language changes... if you left perl for php because perl was ugly (and believe me, I agree), then you should try python. The language is elegance personified. It's a scripting language, so it lacks the performance of Java or C++ for computation-oriented stuff, but the stuff it does, and the simplicity! Often I've seen three short lines of Python code take tens of lines of Java code to accomplish the same task. Python is so readable you rarely need to comment your code if your variable names are well named. It's also fully object oriented, but if you don't like OO for some odd reason, you can do your stuff with just functions.

Wow... what started off as just a few lines turned into a novel. Now I'm all tired and stuff. Can you tell I really like Zope and Python? :)

But I already think to migrate it to accept a bigger user base. The key solution that will lets us doing it is ZEO - Zope Enterprise Objects, which turns the Zope object system into a distributed architecture, allowing multiple processors, machines, and networks to act as one website.

Here is more information from ZEO documentation about when you should use ZEO:

ZEO serves many hits in a fail-safe way. If your site does not get millions of hits, then you probably don't need ZEO. There is no hard-and-fast rule about when you should and should not use ZEO, but for the most part you should not need to run ZEO unless:

• Your site is getting too many hits for your computer to handle them quickly. Zope is a high-performance system, and one Zope can handle millions of hits per day (depending on your hardware, of course). If you need to serve more hits than that, then you should use ZEO.
• Your site is very critical and requires constant, 24/7 uptime. In this case, ZEO will allow you to have multiple fail-over servers.
• You want to distribute your site globally to many different mirror ZEO clients.
• You want to debug one ZEO client while others are still serving requests. This is a very advanced technique for Python developers and is not covered in this book.

Plone is a Zope product that takes it much closer to a commercial content management environment. Zope alone is mostly a framework (though you can do some very cool stuff using only it), but Plone is really the way to go if you want non-technical staff to contribute/manage content.

Of all of these, I like OpenACS the best, mostly because of its developer community. There are a lot of great people involved, and there's a high signal to noise ratio on the developer forums. Even though OpenACS probably has the least of what you're looking for, it might be the easiest to develop. OpenACS runs on top of Postgres or Oracle, and is written in Tcl.

Redhat CCM is basically a Java rewrite of the original OpenACS. Its CMS modules are supposedly more mature. It runs on a Redhat version of Postgres, and I think Oracle too.

Zope is a whole lotta product, and probably has most of what you're looking for. However, I find it kind of murky, difficult to figure out. YMMV.

These three are the most promising in terms of developer community. This is a bigger undertaking than it might seem at the outset. You'll need all the help you can get, and getting involved with these communities will spare you from trying to reinvent the wheel.

Of course, I'd love to have you guys use and extend the OpenACS toolkit, and share your efforts with the community!

It sounds like you're really talking about content management more than version control. Maybe Zope and Plone will do it for you? Out of the box it gives you versioning, authentication and a decent database. The database isn't the most scalable, but you can extend it to use any number of database and database-like backends, like MySQL, PostgreSQL, Berkeley, and various pay-for dbs.

One of our customers ( http://www.amcham.com.br/) uses it extensivelly, as a "front-end" to dynamic web sites running on both a Zope server running on the same machine, and a MS IIS server running on a separate machine. Also, this same Apache also serves up static content residing on files in the same machine.

We also do caching for the "static part" (.gif,.css,.jpg,etc) of the dynamic content, as we have found that this reduces a lot the load on the dynamic servers.

This machine is a (somewhat outdated) Intel PII-Xeon 550Mhz, and serves upwards of 3 million hits per month running Apache 1.3.26 (of course patched-up to fix the latest security holes).

I can attest that this setup works really well: we have never, in 2 years of operations, had ANY downtime because of Apache, and mod_rewrite and mod_proxy indeed do wonders for flexibility and efficiency.

I've been evaluating similiar solutions myself and found that TUTOS and dotproject (both from souceforge) were too incomplete to really meet my needs.

So instead I've been evaluating Content Management Frameworks or Content Management Systems which can easily be adapeted for this use. So Far I've looked at:

Mambo Open Source Which I have found to look and feel great, easy to use, modify, but too lightweight to really meet a project portals needs without significant modification.

Zope
and the CMS based on Zope called Plone
Which I found can fit the bill, but the learning curve is extremely high and may have too much complexity for easy extension development or modification.

Currently I am looking at
Typo3 which seems to fit the bill for both sophistication yet ease of use and extension. However, it doesn't have an extension yet (that I'm aware of) for CVS or a similiar version control system (Would be interested to know if there is one?)

Great resources to check for Open source project management/CMS solutions:
Open and Free Project Management tools
Open Source CMS - Try before you by! with lots of online demo sites available.

Good luck! Follow up with what you decide to use please!

So many questions ;).

Mozilla knows if a response it got is faulty when it came with a http status code which indicated something when wrong, a 404 "Not found", a 500 "Internal Server Error", whatever.
That also explains what I mean with server error.
For example go to
http://slashdot.org/this_gives_us_a_404_not_found

Right click, "view page source". Do this two times. Compare the source code.
You'll see the source codes will differ, because of the slashdot ad rotation (I tried, they differed every time). Additionally, if your connection is slow enough, you'll "feel" the delay when mozilla reloads the page.

When coding in Zope (quick plug, try it and compare to php, it's another world, I went this route myself), it's quite easy and handy to include the error tracebacks into the source of your app, enclosed in html comments, so you have to look at the source to see them. Granted, it's easy to not enclose the tracebacks in html-comments, but it's quite handy to be able to hide the ugly messages from customers on a development server.

Mostly this is no problem with zope, since it's transaction aware and rolls back everything (including sql stuff, no more db->commits and rollbacks sprinkled through your app, nice!) on errors, but the fact stays that I want to see the source of the page I'm looking at, not of something which might, or might not, tell me what went wrong.

Oh, and another gripe I have with mozilla is that it doesn't take the content of textboxes into account when you search on a web page.

Carefully consider this, it could make or break your business if you do not proceed carefully.

Take some time out to read:

There is a lot more information on the topic, feel free to email me if you need a hand with anything

I'll see your karma whoring, and raise you, umm... several:
dotLRN, built on the OpenACS toolkit.
The Future Learning Environment, built on Zope.
The Open Archives Initiative is also interesting for academic information archival projects. Also eprints.org for GPL software for creating archives.

A lot of so-called "distance learning" projects focus their efforts on multimedia transmission - so that a picture of a person talking on screen can be transmitted... big whoop. The projects listed above focus on discussion and content sharing, which is where I think online education will really thrive.

In fact.. Since the Texas Govt. is broke they are cutting back on all expenses. They even wrote the Governor's website using opensource software... and SURPRISE Its been *very* successful!! Have a look at Governor Rick Perry's Website which is running the Zope application server with the Plone Content Management System

TWiki has built-in version-control, so you can recover useful info after the site's been defaced ( if you choose wiki )

Questions, though...

Accessibility: how much?

web-forum is totally accessable, wiki less so.

Do you want whomever can contribute to do so?

I'd use a forum, then, but instead of expecting the forum to produce finished docs, I'd use a moderatable forum to produce raw info ( tips & tricks, experiences, point-up blindnesses in the program's --help listings, etc. ) that could be turned, easily, into user-friendly and complete docs.

Others would prefer a more exclusive wiki, to produce more self-consistent docs...

Do you want the docs to stand on their own?

TWiki's got a plugin that creates non-editable web-page versions of the wiki, so you could deploy it behind a .. password block, and give accounts only to whom-you-trust, and have it automatically create web-pages from the wiki your friends create...

Personally, I'd just go with a forum, and every 6 weeks create a new version of each doc ( and have the comments on that version help me create the next version ).

It'd be as inclusive as possible, it'd force me to perceive where I was creating problems for users' comprehension ( my work's assumptions ), I could put source-code up that way for the parts that were annoying me ( to get as many eyes on it as possible ), it'd be ( from the users perspective ) simpler.

I'd zope ( they're down, right now, some sort of proxy eror? ) it just because then their bookmarks would work...

Why do people insist on comparing Perl with Python? Python is a lot closer to Java in terms of types of programs it will be the best tool for (actually, switching from Java to Python often makes sense in terms of productivity and code maintainability). The most revealing sign is probably that while Perl opens the standard input by default and lets you access it directly with a dedicated keyword, assuming by default that you'll be parsing stuff, Python doesn't, not making risky (for Python) assumptions that would end up being wrong most of the time anyway.

Basically, for a small to medium sized script, Perl is a more effective tool. For anything that will require reusability and modularity (as in, code orthogonality), Python is much more fitting. I guess that a good example could be a comparison of Slashcode (done in Perl) and Zope (done in Python). Comparable idea ('Output stuff on the Web'), but totally different scope.

Just one last thing. Because coding in Perl is fun and it's easy to get carried away at it, some people will try to force it into projects much more complex than it was ever meant for -- resulting in some of those unspeakable code messes we've all seen at some point. Don't let that fool you. For the tasks within its intended scope, Perl is really a good language.

So, which is better? Depends almost solely on what you want to do. If Python has more visibility in academic circles and alike, it's simply because it's a great language to learn about advanced programming concepts and good software design, not because it's 'absolutely better' than Perl. No matter what the biggots on either side will tell you.

I use and like Zope - the nice open-source product fairly directly competing with Interwoven's. I am afraid, the patent can hurt them seriously (and I suspect Zope implemented some ideas first...)

"sorely lacks" may be a bit of an overstatement. The group at Zope has made an Interface module for python. As a first cut for how interfaces could be implemented in python. (I think the fact that they could make an interface implementation without changing the core language says a bit about dynamic languages like python.) In their current implementation, they seem best to be combined with unit tests. A class itself can be imported, even if it doesn't support the interface, but Interface.Verify.verifyClass(ImyInterface, myClass) will return true only for classes that correctly implement the interface.

"sorely lacks" may be a bit of an overstatement. The group at Zope has made an Interface module for python. As a first cut for how interfaces could be implemented in python. (I think the fact that they could make an interface implementation without changing the core language says a bit about dynamic languages like python.) In their current implementation, they seem best to be combined with unit tests. A class itself can be imported, even if it doesn't support the interface, but Interface.Verify.verifyClass(ImyInterface, myClass) will return true only for classes that correctly implement the interface.

"sorely lacks" may be a bit of an overstatement. The group at Zope has made an Interface module for python. As a first cut for how interfaces could be implemented in python. (I think the fact that they could make an interface implementation without changing the core language says a bit about dynamic languages like python.) In their current implementation, they seem best to be combined with unit tests. A class itself can be imported, even if it doesn't support the interface, but Interface.Verify.verifyClass(ImyInterface, myClass) will return true only for classes that correctly implement the interface.

PHP is good for its ubiquity...

Many servers already run it or can be convinced to run it with no problems.

But if you have the opportunity to roll your own server then you really should be using Zope.

Based on Python, the functionality of zope and the elegance of its implementation, really blows PHP away.

PHP will never fill the application server market the way that JSP does and
that Zope will.

If you want to see why PHP is good for quick and dirty little sites that want to be run cheaply on commodity hardware, but why JSP really rock - then check out the article on aceshardware about the rationale of setting up a java based sytem.

PHP is great but after you use Zope you won't want to go back to PHP ever again.

PHP is good for its ubiquity...

Many servers already run it or can be convinced to run it with no problems.

But if you have the opportunity to roll your own server then you really should be using Zope.

Based on Python, the functionality of zope and the elegance of its implementation, really blows PHP away.

PHP will never fill the application server market the way that JSP does and
that Zope will.

If you want to see why PHP is good for quick and dirty little sites that want to be run cheaply on commodity hardware, but why JSP really rock - then check out the article on aceshardware about the rationale of setting up a java based sytem.

PHP is great but after you use Zope you won't want to go back to PHP ever again.

One new, and cool, Perl XML module that people might not know about is Petal (PErl Template Attribute Language).

It is an implementation of the Zope TAL (Template Attribute Language) specification and it basically allows you to create XML templates where all the templating commands are just attributes of existing tags.

This allows things like XHTML templates which are very WYSIWYG friendly since the editors don't do anything with attributes that they don't know about.

Heh, hehe, okay.

According to Bagley's site, we should all be using Ocaml anyway. Who knows, he may even be right...

In reference to the Bagley test, Java was more performant than Python, true. But Python won over Java on both memory and lines of code. Also, his tests, as all artificial benchmarks, are both accurate only for the point-in-time and are only accurate within the limits of the test conditions themselves. More recent versions of both Java and Python are faster. On top of that, special-purpose optimizations exist for both Java and Python if you really need that extra spurt of speed -- think Jikes or TowerJ for Java and Psyco for Python. More to the point, though, Java may be faster than Python, but it isn't faster by an order of magnitude. The difference in speed between them is not enough to worry about -- if you really need that much speed, you won't be programming in either Java *or* Python, you'll be coding in C and assembler. Your performance argument is irrelevant.

Your libraries argument is somewhat more compelling. However, you may not be aware that there are two major versions of Python, standard Python implemented in C and Jython, implemented in Java. Using Jython, you can write Python that has full access to all of Java's libraries.

On top of that, I'll make a very rough comparison between the various projects on Jakarta and extant Python libraries. I don't think I've seen anything like this, as Python has a poor record for collating their libraries and apps in one place, so the effort is worth it simply for educational purposes, if nothing else.

Disclaimer: I am not terribly familiar with most of these projects, and they have varying states of completeness and maturity. I merely aim to show that analogs of the various Jakarta projects do exist in the Python world. Please feel free to peruse them yourself and come to your own conclusions.

Jakarta Ant -- PyAnt , SCons

Alexandria -- I don't know of any comparable Python applications. However, the individual components of Alexandria (doc generation, CVS access, etc.) are available: check out HappyDoc , and various modules for use with the Zope application server, including CVSFile

Okay, now I'm going to lump together a bunch of Jakarta projects. Individual authors and users of these projects will inevitably scream, but my justification is that they are all web application servers of one sort or another. Their purposes are all the same. They have many differences in approach, philosophy, scope, and implementation, but at heart, they are all web application servers or web application server frameworks. Those projects are: Avalon, Jetspeed, Struts, Turbine, Velocity, Slide, and Tomcat itself. Oh, and I might as well throw James in here, too. Python web app servers and frameworks are equally numerous, and several are in advanced stages of maturity: again Zope, Twisted, Webware, Quixote, CherryPy, and SkunkWeb. There are more, but I'll leave that as an exercise for the reader. Google is your friend.

Lucene has no real counterpart in Python. David Mertz has put together a text indexer and search program, available at his site, but it looks small compared to Lucene. There is also something called WePaSe, but there is no information on it aside from its freshmeat release announcement.

Gump also has no counterpart. Cactus has an equivalent in WebUnit and PyUnit. Log4J's Python copy is called, naturally, Log4Py.

ORO and Regexp provide regular expressions for Java. Python has regular expressions built in to the standard library.

OJB provides an object-relational bridge for Java, similar in concept to Sun's JDO specification. Python counterparts are Modeling , PyDO, which is a subproject of the above-mentioned SkunkWeb, and MiddleKit, a subproject of WebWare.

ECS, JMeter, and POI have no Python counterparts. BSF also has no counterpart, since it embeds a scripting language in compiled Java. Perhaps its "counterpart" is Jython. Likewise, BCEL has no counterpart, nor does Watchdog.

Taglibs has no direct counterpart. Instead, Python has Spyce, Cheetah, PSP, and probably close to a dozen other implementations of the ASP/JSP theme, each with their own library of tags. Lack of a standard is perhaps not a good thing, but the existence of bunches of competing implementations is not a bad thing. Perhaps the most direct counterpart would be Zope's built-in technologies, DTML and ZPT. ZPT has also been built out into a standalone version, SimpleTAL.

Jakarta Commons has too many small projects for me to want to research Python equivalents. If you are looking for something in particular, check the Vaults of Parnassus first.

As for Apache XML, Python has SOAPy and ZSI implementing SOAP, and DOM, SAX, and XML-RPC are built in to the standard library. 4Suite implements DOM, SAX, RDF, XSLT, XInclude, XPointer, XLink and XPath, and has an XML and RDF data repository and server built on top, which would make it very roughly equivalent to both Cocoon and Xindice. I don't know of any Python equivalents for Batik, FOP or XMLSecurity.

Python has relational database access through its DBAPI standard, with adaptors for just about every database. There are a number of object databases coded specifically for (and often in) Python, the most well known being ZODB, which was developed by Zope. There are adaptors for other object databases as well.

There are really two spaces where Java outstrips Python, and the second space is IMHO directly caused by the first: standardization, and J2EE. Python puts out a language implementation and a lot of very useful libraries, but does not have any standardization body like the JCP. The result is lots of fragmentation. Individual developers write their own libraries and applications that compete with each other while offering wildly differing APIs and programming approaches. There has been some push to organize, through the official Python SIGs, but their efforts, while noble, have not been massively effective. Only this month has an initial implementation of a Python library repository similar to CPAN been released. Kudos to Andrew Kuchling, who made it happen, but it is LONG overdue.

Regarding J2EE, the only viable competitor is Zope. Even then, Zope really doesn't address the same problem space. The shortfall here comes from a number of different factors: corporate buy-in, public perception, lack of an established problem-space solution, and lack of published standards. Zope is a great solution, and has been used by a number of high-profile companies, but its focus is different.

Well, I hope you find this comparison to be useful. *I* certainly found it enlightening.

Heh, hehe, okay.

According to Bagley's site, we should all be using Ocaml anyway. Who knows, he may even be right...

In reference to the Bagley test, Java was more performant than Python, true. But Python won over Java on both memory and lines of code. Also, his tests, as all artificial benchmarks, are both accurate only for the point-in-time and are only accurate within the limits of the test conditions themselves. More recent versions of both Java and Python are faster. On top of that, special-purpose optimizations exist for both Java and Python if you really need that extra spurt of speed -- think Jikes or TowerJ for Java and Psyco for Python. More to the point, though, Java may be faster than Python, but it isn't faster by an order of magnitude. The difference in speed between them is not enough to worry about -- if you really need that much speed, you won't be programming in either Java *or* Python, you'll be coding in C and assembler. Your performance argument is irrelevant.

Your libraries argument is somewhat more compelling. However, you may not be aware that there are two major versions of Python, standard Python implemented in C and Jython, implemented in Java. Using Jython, you can write Python that has full access to all of Java's libraries.

On top of that, I'll make a very rough comparison between the various projects on Jakarta and extant Python libraries. I don't think I've seen anything like this, as Python has a poor record for collating their libraries and apps in one place, so the effort is worth it simply for educational purposes, if nothing else.

Disclaimer: I am not terribly familiar with most of these projects, and they have varying states of completeness and maturity. I merely aim to show that analogs of the various Jakarta projects do exist in the Python world. Please feel free to peruse them yourself and come to your own conclusions.

Jakarta Ant -- PyAnt , SCons

Alexandria -- I don't know of any comparable Python applications. However, the individual components of Alexandria (doc generation, CVS access, etc.) are available: check out HappyDoc , and various modules for use with the Zope application server, including CVSFile

Okay, now I'm going to lump together a bunch of Jakarta projects. Individual authors and users of these projects will inevitably scream, but my justification is that they are all web application servers of one sort or another. Their purposes are all the same. They have many differences in approach, philosophy, scope, and implementation, but at heart, they are all web application servers or web application server frameworks. Those projects are: Avalon, Jetspeed, Struts, Turbine, Velocity, Slide, and Tomcat itself. Oh, and I might as well throw James in here, too. Python web app servers and frameworks are equally numerous, and several are in advanced stages of maturity: again Zope, Twisted, Webware, Quixote, CherryPy, and SkunkWeb. There are more, but I'll leave that as an exercise for the reader. Google is your friend.

Lucene has no real counterpart in Python. David Mertz has put together a text indexer and search program, available at his site, but it looks small compared to Lucene. There is also something called WePaSe, but there is no information on it aside from its freshmeat release announcement.

Gump also has no counterpart. Cactus has an equivalent in WebUnit and PyUnit. Log4J's Python copy is called, naturally, Log4Py.

ORO and Regexp provide regular expressions for Java. Python has regular expressions built in to the standard library.

OJB provides an object-relational bridge for Java, similar in concept to Sun's JDO specification. Python counterparts are Modeling , PyDO, which is a subproject of the above-mentioned SkunkWeb, and MiddleKit, a subproject of WebWare.

ECS, JMeter, and POI have no Python counterparts. BSF also has no counterpart, since it embeds a scripting language in compiled Java. Perhaps its "counterpart" is Jython. Likewise, BCEL has no counterpart, nor does Watchdog.

Taglibs has no direct counterpart. Instead, Python has Spyce, Cheetah, PSP, and probably close to a dozen other implementations of the ASP/JSP theme, each with their own library of tags. Lack of a standard is perhaps not a good thing, but the existence of bunches of competing implementations is not a bad thing. Perhaps the most direct counterpart would be Zope's built-in technologies, DTML and ZPT. ZPT has also been built out into a standalone version, SimpleTAL.

Jakarta Commons has too many small projects for me to want to research Python equivalents. If you are looking for something in particular, check the Vaults of Parnassus first.

As for Apache XML, Python has SOAPy and ZSI implementing SOAP, and DOM, SAX, and XML-RPC are built in to the standard library. 4Suite implements DOM, SAX, RDF, XSLT, XInclude, XPointer, XLink and XPath, and has an XML and RDF data repository and server built on top, which would make it very roughly equivalent to both Cocoon and Xindice. I don't know of any Python equivalents for Batik, FOP or XMLSecurity.

Python has relational database access through its DBAPI standard, with adaptors for just about every database. There are a number of object databases coded specifically for (and often in) Python, the most well known being ZODB, which was developed by Zope. There are adaptors for other object databases as well.

There are really two spaces where Java outstrips Python, and the second space is IMHO directly caused by the first: standardization, and J2EE. Python puts out a language implementation and a lot of very useful libraries, but does not have any standardization body like the JCP. The result is lots of fragmentation. Individual developers write their own libraries and applications that compete with each other while offering wildly differing APIs and programming approaches. There has been some push to organize, through the official Python SIGs, but their efforts, while noble, have not been massively effective. Only this month has an initial implementation of a Python library repository similar to CPAN been released. Kudos to Andrew Kuchling, who made it happen, but it is LONG overdue.

Regarding J2EE, the only viable competitor is Zope. Even then, Zope really doesn't address the same problem space. The shortfall here comes from a number of different factors: corporate buy-in, public perception, lack of an established problem-space solution, and lack of published standards. Zope is a great solution, and has been used by a number of high-profile companies, but its focus is different.

Well, I hope you find this comparison to be useful. *I* certainly found it enlightening.

Heh, hehe, okay.

According to Bagley's site, we should all be using Ocaml anyway. Who knows, he may even be right...

In reference to the Bagley test, Java was more performant than Python, true. But Python won over Java on both memory and lines of code. Also, his tests, as all artificial benchmarks, are both accurate only for the point-in-time and are only accurate within the limits of the test conditions themselves. More recent versions of both Java and Python are faster. On top of that, special-purpose optimizations exist for both Java and Python if you really need that extra spurt of speed -- think Jikes or TowerJ for Java and Psyco for Python. More to the point, though, Java may be faster than Python, but it isn't faster by an order of magnitude. The difference in speed between them is not enough to worry about -- if you really need that much speed, you won't be programming in either Java *or* Python, you'll be coding in C and assembler. Your performance argument is irrelevant.

Your libraries argument is somewhat more compelling. However, you may not be aware that there are two major versions of Python, standard Python implemented in C and Jython, implemented in Java. Using Jython, you can write Python that has full access to all of Java's libraries.

On top of that, I'll make a very rough comparison between the various projects on Jakarta and extant Python libraries. I don't think I've seen anything like this, as Python has a poor record for collating their libraries and apps in one place, so the effort is worth it simply for educational purposes, if nothing else.

Disclaimer: I am not terribly familiar with most of these projects, and they have varying states of completeness and maturity. I merely aim to show that analogs of the various Jakarta projects do exist in the Python world. Please feel free to peruse them yourself and come to your own conclusions.

Jakarta Ant -- PyAnt , SCons

Alexandria -- I don't know of any comparable Python applications. However, the individual components of Alexandria (doc generation, CVS access, etc.) are available: check out HappyDoc , and various modules for use with the Zope application server, including CVSFile

Okay, now I'm going to lump together a bunch of Jakarta projects. Individual authors and users of these projects will inevitably scream, but my justification is that they are all web application servers of one sort or another. Their purposes are all the same. They have many differences in approach, philosophy, scope, and implementation, but at heart, they are all web application servers or web application server frameworks. Those projects are: Avalon, Jetspeed, Struts, Turbine, Velocity, Slide, and Tomcat itself. Oh, and I might as well throw James in here, too. Python web app servers and frameworks are equally numerous, and several are in advanced stages of maturity: again Zope, Twisted, Webware, Quixote, CherryPy, and SkunkWeb. There are more, but I'll leave that as an exercise for the reader. Google is your friend.

Lucene has no real counterpart in Python. David Mertz has put together a text indexer and search program, available at his site, but it looks small compared to Lucene. There is also something called WePaSe, but there is no information on it aside from its freshmeat release announcement.

Gump also has no counterpart. Cactus has an equivalent in WebUnit and PyUnit. Log4J's Python copy is called, naturally, Log4Py.

ORO and Regexp provide regular expressions for Java. Python has regular expressions built in to the standard library.

OJB provides an object-relational bridge for Java, similar in concept to Sun's JDO specification. Python counterparts are Modeling , PyDO, which is a subproject of the above-mentioned SkunkWeb, and MiddleKit, a subproject of WebWare.

ECS, JMeter, and POI have no Python counterparts. BSF also has no counterpart, since it embeds a scripting language in compiled Java. Perhaps its "counterpart" is Jython. Likewise, BCEL has no counterpart, nor does Watchdog.

Taglibs has no direct counterpart. Instead, Python has Spyce, Cheetah, PSP, and probably close to a dozen other implementations of the ASP/JSP theme, each with their own library of tags. Lack of a standard is perhaps not a good thing, but the existence of bunches of competing implementations is not a bad thing. Perhaps the most direct counterpart would be Zope's built-in technologies, DTML and ZPT. ZPT has also been built out into a standalone version, SimpleTAL.

Jakarta Commons has too many small projects for me to want to research Python equivalents. If you are looking for something in particular, check the Vaults of Parnassus first.

As for Apache XML, Python has SOAPy and ZSI implementing SOAP, and DOM, SAX, and XML-RPC are built in to the standard library. 4Suite implements DOM, SAX, RDF, XSLT, XInclude, XPointer, XLink and XPath, and has an XML and RDF data repository and server built on top, which would make it very roughly equivalent to both Cocoon and Xindice. I don't know of any Python equivalents for Batik, FOP or XMLSecurity.

Python has relational database access through its DBAPI standard, with adaptors for just about every database. There are a number of object databases coded specifically for (and often in) Python, the most well known being ZODB, which was developed by Zope. There are adaptors for other object databases as well.

There are really two spaces where Java outstrips Python, and the second space is IMHO directly caused by the first: standardization, and J2EE. Python puts out a language implementation and a lot of very useful libraries, but does not have any standardization body like the JCP. The result is lots of fragmentation. Individual developers write their own libraries and applications that compete with each other while offering wildly differing APIs and programming approaches. There has been some push to organize, through the official Python SIGs, but their efforts, while noble, have not been massively effective. Only this month has an initial implementation of a Python library repository similar to CPAN been released. Kudos to Andrew Kuchling, who made it happen, but it is LONG overdue.

Regarding J2EE, the only viable competitor is Zope. Even then, Zope really doesn't address the same problem space. The shortfall here comes from a number of different factors: corporate buy-in, public perception, lack of an established problem-space solution, and lack of published standards. Zope is a great solution, and has been used by a number of high-profile companies, but its focus is different.

Well, I hope you find this comparison to be useful. *I* certainly found it enlightening.

I like this guys enthusiasm for open source.

I have questions though about the users ability to apply meaning attributes to the numerous amounts of content. If the user fails to provide meaningfull attributes the system fails to provide the user with meaningful results. In which case I would judge this system to less user-friendly because the files would be returned in a 1 big lump.

This idea stricks me as an implementation of something similar to the Dublin Core Metadata Initiative except for local content. Wouldn't this project benefit from enabling the user to manage ALL types of information, even remote. It wouldn't be a large stretch of the imagination to take that step.

If anybody is interested how the Dublin Core works in application you might want to check out the Zope CMF(Content Management Framework).

My experience from using Zope's CMF is that the initial learning process of a user using this method of organiztion was slow and bumpy. Although I must point out that my experience with the system was only with using a single implementation, so I'm not making the assertion that an implementation couldn't be designed that could improve the learning curve for users.

I would also like to point out to the people that have said this would ruin Linux that they don't understand exactly what this tool does. Its a means of effeciently catalogging and managing content. Any use of the tool does not restrict the user to that tool alone; it can be used in conjunction with the traditional HFS. The author even says so in the article.

You should consider switching to the Zope platform. Although XML parsing is not yet out-of-the-box in Zope, there are several products for the platform available free of charge that should do what you want it to do.

How about a login/password box (and NOT using the antiquated HTTP method of authenication - for one, it has no way to "logout" a user).

Funny you should mention it. I installed Zope recently on one of my Debian boxen. I noticed it uses HTTP Basic Authentication, the "antiquated" (read: standard, universal) mechanism to which you refer. It also has a "Logout" button that works -- if you select "Logout", it returns a page with an authentication failure code, which a browser interprets as meaning that the (username, password) pair it is caching is invalid.

The fact that you, or your Web application developer, did not think of that indicates that the Zope people know HTTP better than you or s/he. It certainly doesn't indicate anything the matter with HTTP Basic Authentication. And there's a lot right with using the protocol's built-in authentication mechanism rather than writing your own: it is easier; it requires less code; it is standard and works everywhere, unlike JavaScript; and it is better tested than any new mechanism you invent, meaning that it is less likely to fail badly and let people crack your application.

...or why python is better on the backend and the front-end.

Take namespaces for special-purpose library stuff. Or inline eval (include) of logic code (bad, bad, bad). Good analysis (mine) here, including comparitive code to demonstrate my point.

Like Java, Python already does assignment by reference, copy is optional. PHP is just figuring this out. PHP's language leaves much to be desired in team programming and code readability. Using 'Design Patterns' is only half the equation. You can do component oriented programming, but some languages are going to be better than others at facilitaing it in a manner that works in reality. PHP5, unfortunately, won't hold a candle to Zope 3, which is really going to compete at the level of J2EE and .NET as well-thought-out enterprise component frameworks.

PHP lacks object persistence, multiple inheritance, full-featured transaction machinery, a built-in security model, an interactive command-line interpreter, and it is too tied to web-scripting only. And becuase it doesn't have a security model that binds operations to roles/permissions, it can't easily put gateway methods with bound roles (like Zope's proxy roles) between web code and SQL code, leading to increased chance of SQL injection vulnerabilities.

On the other hand, Zope has object perisistence, transactional RDBMS integration and connection abstraction, templated, componentized SQL methods, a security framework, and Python, which is a much better language (explicit is better than implicit). And if you need to do any sort of content-management, Zope has a mature component-oriented framwork in the CMF, with a killer-app implementation in Plone. It also has XML-RPC, WebDAV, Caching managers, and all sorts of other goodies you won't find out of the box in PHP.

PHP is fast, and it is easy, but it is by no means scalable. PHP offers a gentle slope learning-curve, and quick easy hacks, but is somewhat like a crack addiction. What PHP as a framework needs to do is not reinvent the wheel in the language department, and use a pre-existing, scalable, enterprise-class OO scripting language, and utilize a templating technology that doesn't promote mixing logic and presentation - but what's the point, since it would look remarkably like Zope?

...or why python is better on the backend and the front-end.

Take namespaces for special-purpose library stuff. Or inline eval (include) of logic code (bad, bad, bad). Good analysis (mine) here, including comparitive code to demonstrate my point.

Like Java, Python already does assignment by reference, copy is optional. PHP is just figuring this out. PHP's language leaves much to be desired in team programming and code readability. Using 'Design Patterns' is only half the equation. You can do component oriented programming, but some languages are going to be better than others at facilitaing it in a manner that works in reality. PHP5, unfortunately, won't hold a candle to Zope 3, which is really going to compete at the level of J2EE and .NET as well-thought-out enterprise component frameworks.

PHP lacks object persistence, multiple inheritance, full-featured transaction machinery, a built-in security model, an interactive command-line interpreter, and it is too tied to web-scripting only. And becuase it doesn't have a security model that binds operations to roles/permissions, it can't easily put gateway methods with bound roles (like Zope's proxy roles) between web code and SQL code, leading to increased chance of SQL injection vulnerabilities.

On the other hand, Zope has object perisistence, transactional RDBMS integration and connection abstraction, templated, componentized SQL methods, a security framework, and Python, which is a much better language (explicit is better than implicit). And if you need to do any sort of content-management, Zope has a mature component-oriented framwork in the CMF, with a killer-app implementation in Plone. It also has XML-RPC, WebDAV, Caching managers, and all sorts of other goodies you won't find out of the box in PHP.

PHP is fast, and it is easy, but it is by no means scalable. PHP offers a gentle slope learning-curve, and quick easy hacks, but is somewhat like a crack addiction. What PHP as a framework needs to do is not reinvent the wheel in the language department, and use a pre-existing, scalable, enterprise-class OO scripting language, and utilize a templating technology that doesn't promote mixing logic and presentation - but what's the point, since it would look remarkably like Zope?

...or why python is better on the backend and the front-end.

Take namespaces for special-purpose library stuff. Or inline eval (include) of logic code (bad, bad, bad). Good analysis (mine) here, including comparitive code to demonstrate my point.

Like Java, Python already does assignment by reference, copy is optional. PHP is just figuring this out. PHP's language leaves much to be desired in team programming and code readability. Using 'Design Patterns' is only half the equation. You can do component oriented programming, but some languages are going to be better than others at facilitaing it in a manner that works in reality. PHP5, unfortunately, won't hold a candle to Zope 3, which is really going to compete at the level of J2EE and .NET as well-thought-out enterprise component frameworks.

PHP lacks object persistence, multiple inheritance, full-featured transaction machinery, a built-in security model, an interactive command-line interpreter, and it is too tied to web-scripting only. And becuase it doesn't have a security model that binds operations to roles/permissions, it can't easily put gateway methods with bound roles (like Zope's proxy roles) between web code and SQL code, leading to increased chance of SQL injection vulnerabilities.

On the other hand, Zope has object perisistence, transactional RDBMS integration and connection abstraction, templated, componentized SQL methods, a security framework, and Python, which is a much better language (explicit is better than implicit). And if you need to do any sort of content-management, Zope has a mature component-oriented framwork in the CMF, with a killer-app implementation in Plone. It also has XML-RPC, WebDAV, Caching managers, and all sorts of other goodies you won't find out of the box in PHP.

PHP is fast, and it is easy, but it is by no means scalable. PHP offers a gentle slope learning-curve, and quick easy hacks, but is somewhat like a crack addiction. What PHP as a framework needs to do is not reinvent the wheel in the language department, and use a pre-existing, scalable, enterprise-class OO scripting language, and utilize a templating technology that doesn't promote mixing logic and presentation - but what's the point, since it would look remarkably like Zope?

Next time try looking into Zope. It's an outstanding platform for web-applications and dynamic web content.

It sucks for static through-put of files, however, so if you plan to serve large files stick with Apache. But if you want dynamic content -- go Zope.

One thing that stirkes about PHP is it's position in the market. It simply ownz all other SSI technologies out there. From ASP over JSP to Cold Fusion, PHP is one of the outstanding successes of OSS.
Yet all these SSI technologies have in common that they still don't manage to really split Design from content. I was all in for PHP as my way of doing SSI stuff until I ran into TAL. It's the second (next to DTML) SSI Language that comes with Zope and has been reimplemented in Perl (PETAL). The essential difference to other SSI solutions like the #1 PHP is that all SSI-relevant tags only come as parameters to standard HTML tags and thus absolutly don't interfere with WYSIWYG HTML tools or other stuff that belongs to markup. You even can get good editors to switch of the non-html tal parameters to do your markup uninterfered. Once on the server content of tal-parametered markup (tal-speak: "mockup") get's replaced with the dynamic content. The point is: Either way you have documents that can be previewed in browsers, edited and formated without the source code for serverside dynamics being touched - or vice versa.
A simple trick to establish true separation of content and code.

And DTML, in case you were wondering, is the old, deprecated markup language of Zope, now largely replaced by TAL, TALES and METAL.

You may mean PHP, I guess? I agrre, it's complete mess of spaghetti.

But in a defence of open source project (especially based on something else than on proprietary java) I would address you to Zope. You'll find a very good technology design without all that EJBish overbloating.

When you run Zope, please check you memory. Compare it to what you have with Struts/JBoss on an equal load and equal functions (and equal dev time). In my case the difference was 10 MB vs 100 MB for a mid size applications.

After that compare you code just to enjoy that your application code in Zope is even more readable and better mainanable than in Struts.

I began to hate EJB specifically and Java generally when I've been introduced to Zope and Python.

ZOPE!

Water looks remarkably like ColdFusion... XML or not... I've used ColdFusion for quite some time, and separating logic and content is really difficult.

Zope Page Templates is the fisrt solution I've seen so far which really separates content and code, while enabling editing of dynamic templates in a regular html editor...

The makers of Gimp don't seem to be interested in adding this functionality, though, so we'll have to turn to Zope or Kontour for that functionality
--