Zope is a web application server with an integrated object relational database and a turnkey web administration frontend. It's basically a prototype of what application servers and databases are going to look like in 5 to 10 years. From having worked with Zope I can say the power of this tool simply is breathtaking. Technology wise it's way beyond anything else I've seen, including J2EE and the bazillion other Appservers that come with it and other to-date solutions like the ones based on.Net. It's downsides were the lack of consitent documentation for some parts, slow extra basic components (called "Products") and a lack of filtering in the Zope community. Like top grade Zope solutions right next to crappy beta level coding experiments. Lot of this has improved throughout the last 2 years though. Still missing is a larger support by ISPs running Zope on their servers. Bottom line: If anyone wants to build a special application with lot of custom server side programming, Zope is the powertool of choice. Technology wise it beats any other solution hands down. Think "The Linux of Application Servers".
-- We suffer more in our imagination than in reality. - Seneca
Re:OK we need some input from the Zope heads
by
Dub+Kat
·
· Score: 5, Interesting
"Is it compiled into native code? I know this is more a Python thing but even mentioning an application server built in a scripting language will have me ridiculed out the door."
You're saying you'll be ridiculed for proposing an application server using an interpreted language, because it supposedly can't keep up with a J2EE server?
Maybe Zope, Inc.'s customers disagree. Or photo.net, a site getting over 10,000,000 hits a day that's written in OpenACS, which is itself written totally in Tcl?
If you feel forced to keep using J2EE because you'll be ridiculed otherwise for using a "non-compiled" app server, go ahead. But other developers are likely gaining a lot of productivity by using more dynamic and "slower" interpreted languages. Check out this 22MB quicktime demo movie of the Ruby on Rails framework...pretty awesome stuff.
Zope great in theory ... not so much in practice.
by
barwin
·
· Score: 5, Interesting
I used to work for a web development firm that slowly went from a primarily Java based atmosphere to an all Zope based model.
Zope looks great on paper, and it was [relatively] easy to convince Management that it would "increase productivity", and would be "easy for the Java developers to learn and switch to". In all fairness, even the Java developers I worked with would agree that Zope offered some great features that other languages didn't offer. Aquisition, for one.
In practice, our Zope projects ended up being disasters. Slow, difficult to develop and debug. (By default, all of your code editing is done using the web based editor, which is just a simple HTML TextArea input). It does NOT lend itself well to development teams of more than a few people, and is so inefficient that you *must* use a caching proxy if you expect any substantial amount of traffic.
It's been about 6 months since I stopped developing in Zope, and I must say my sanity level has increased since then. Of course, I have not tried Zope 3 yet (which was rewritten from scratch apparently), so it definitely deserves a fair shot. I'm simply relaying my past experiences with the Zope 2.5 thru 2.7 versions, for whatever it's worth.
Zope is a web application server with an integrated object relational database and a turnkey web administration frontend. .Net.
It's basically a prototype of what application servers and databases are going to look like in 5 to 10 years.
From having worked with Zope I can say the power of this tool simply is breathtaking. Technology wise it's way beyond anything else I've seen, including J2EE and the bazillion other Appservers that come with it and other to-date solutions like the ones based on
It's downsides were the lack of consitent documentation for some parts, slow extra basic components (called "Products") and a lack of filtering in the Zope community. Like top grade Zope solutions right next to crappy beta level coding experiments. Lot of this has improved throughout the last 2 years though. Still missing is a larger support by ISPs running Zope on their servers.
Bottom line:
If anyone wants to build a special application with lot of custom server side programming, Zope is the powertool of choice. Technology wise it beats any other solution hands down. Think "The Linux of Application Servers".
We suffer more in our imagination than in reality. - Seneca
"Is it compiled into native code? I know this is more a Python thing but even mentioning an application server built in a scripting language will have me ridiculed out the door."
You're saying you'll be ridiculed for proposing an application server using an interpreted language, because it supposedly can't keep up with a J2EE server?
Maybe Zope, Inc.'s customers disagree. Or photo.net, a site getting over 10,000,000 hits a day that's written in OpenACS, which is itself written totally in Tcl?
If you feel forced to keep using J2EE because you'll be ridiculed otherwise for using a "non-compiled" app server, go ahead. But other developers are likely gaining a lot of productivity by using more dynamic and "slower" interpreted languages. Check out this 22MB quicktime demo movie of the Ruby on Rails framework...pretty awesome stuff.
Linux Virtual Private Servers for Professionals
I used to work for a web development firm that slowly went from a primarily Java based atmosphere to an all Zope based model.
Zope looks great on paper, and it was [relatively] easy to convince Management that it would "increase productivity", and would be "easy for the Java developers to learn and switch to". In all fairness, even the Java developers I worked with would agree that Zope offered some great features that other languages didn't offer. Aquisition, for one.
In practice, our Zope projects ended up being disasters. Slow, difficult to develop and debug. (By default, all of your code editing is done using the web based editor, which is just a simple HTML TextArea input). It does NOT lend itself well to development teams of more than a few people, and is so inefficient that you *must* use a caching proxy if you expect any substantial amount of traffic.
It's been about 6 months since I stopped developing in Zope, and I must say my sanity level has increased since then. Of course, I have not tried Zope 3 yet (which was rewritten from scratch apparently), so it definitely deserves a fair shot. I'm simply relaying my past experiences with the Zope 2.5 thru 2.7 versions, for whatever it's worth.