...

I need to present the arguments for why we haev chosen Zope vs. Others. Does anyone know of a clear at-a-glance table or anything with the main contenders, features, price, licensing etc.

You didn't collect this data _before_ choosing Zope? :-)

lol not really.. back then it seemed obvious to me why to try zope what's interesting about it: zope_pros = ['idea', 'free', 'openSource', 'Zserver', 'ZODB', 'x-platform', 'persistence', 'python', 'DTML', 'community', 'zopezen', 'scale and scope', 'easy install', 'External Methods', '.zexp files'] and what's to watch out for zope_cons = ['DTML', 'documentation', 'lack of books', 'lack of demonstrable large commercial or cool sites', 'lack of visual design sense' 'versionitis', 'zopezen', 'learning curve', 'DTML interface/edit-test cycle'] ...to be clearer in a wide context As I see it these are the alternative choices: <name> - Zope - ColdFusion - ASP - Roxen - Vignette - AOLserver/ArsDigita - Manila ? Do you agree? What's missing? For each of above I'd like to fill in the following: {'name':"<name>", 'features':{<feature dict>},'pro':[<pros>], 'con':[<cons>] } where <feature dict> = {'OS': [], 'Xplatform':[], 'cost':[] , 'sourcecode':[], 'license':[], 'openSource':[] 'version':[], 'scriptinglanguages':[], 'DBconnectivity':[] ) Any takers? If was more adept in DTML was I could put up a comparative poll page though I suspect most here would respond like you Nils. cheers - Jason

Hi Nils thanks for your reply

...

What's missing?

For example, everything with Java (e.g. Apple WebObjects) or Perl (e.g. Mason).

[doh] Java..Right [see what using zope does to one ? ;-)

There is a good overview of Content Management Systems at

http://www.camworld.com/cms/

Excellent. Thanks very much for this. and supplying a magic_phrase = 'Content Management System'

...

For each of above I'd like to fill in the following:

{'name':"<name>", 'features':{<feature dict>},'pro':[<pros>], 'con':[<cons>] }

That's a bit difficult to do because we don't know what you want to do with a CMS/web application platform. Manila, for instance, is a nice end-user weblog application but not a replacement for a real web app server.

Yes of course not. But imagine one meets up with a small group of experienced people who have all been working around Content Management Systems, are in Zope and are tracking the developments both potential and RealWorld(tm). The you ask them ok to get started can please resume for me zope and alternative systems according you whatever priorities/experiences you wish. That conversation is _not_ going to read like a research document. It is going be opinionated, informed, direct and typically subjectively prioritized.. and damn helpful I agree about Manila. pros = ['good idea', 'great community', 'cool interesting RealWorld sites', 'designer-savvy', 'very user friendly' ] cons = ['mac/win only', 'does not scale well to become 'real' web app server', etc..] What is very impressive is that it has focused on some real end user need and answered that in large part. Zope could learn a lot from Manila. [Zopefish etc]. Mostly Zope imho is just plain damn ugly out of the box... like some ghost from the 70s - zero graphics sense.. it s a bitch to make a decventlooking page in zope when it shouldn't be, not one nice looking zope site I have visited yet vs. all those nice looking nice reading Weblogs. Why?? Well Zope is very cool and powerful adn full of potential but try to use it and even seasoned programmers become unraveled in obfuscated syntax, etc etc. I love what Zope represents, what it _can_ do, but I do not like what I see people actually doing with it. This continues to bother me and I keep my eye on where the alternatives are going for much the same reasons. Jeff Shelton has been putting up great service with his ZopeNewbies page. Not an accident that he is running it on Manila - because Manila makes it easy to set this stuff up and keep it going. Zope does not. In part the difference are that Manila attracts a more aesthetically [visually] aware crowd than Zope. Zope is geeky and damn proud of it. Zope rocks but there are no rocking zope sites that I can tell. Please correct me if I am wrong. [yes I am Awaiting some real news about CBS etc] But look at the 'Case Studies' page.. It is not even titled 'Sites using Zope' instead "The following are a list of case studies in which Zope provided the solution." Reading between the lines it does not inspire great confidence. Nor does there appear to Is the problem with the tool the technology or the users?? It is not an either or question - its a synergy issue.. But Zope does nothing to encourage one alas nor do the examples out there, [yet]. Imagine if the home page at www.zope.org was built using Manila? I'll bet it would be more dynamic more readable, more fun, more useful that it is now. Even having a damn calendar to browse through developments, news adn changes would be good. Not to mention the decidedly dead and strange style and links. What a shame. But it does not stop me loving what is cool about zope or trying to use it. But as soon as more Manila-like Zope comes along I am likely going to jump ship, because Zope is expensive to run. I am not talking about the free price, I am talking about the counter-intuitive chaotically undocumented nature of Zope. And that costs developer time wickedly..Yes I know it is changing and improving and I am holding on and hanging in there, hoping a) it improves and b) I improve..

...

If was more adept in DTML was I could put up a comparative poll page though I suspect most here would respond like you Nils.

I'm only an innocent Computer Science student who still thinks that in Real Life (tm) outside university you research competing solutions before selecting a product :-)

Of course you are right in this respect. We did that and For-what-we-wanted-to-do, Zope met the most important criteria. But our Project proposal was written and given the initial green light over 1 year ago. It was an experiment to use zope then , and the experiment is still running. In brief I continue to be very impressed by portable import/export features of Zope. But we have elected to use External Methods to bypass lack-of-confidence and some of the headaches we experienced doing things with DTML. We like the resultant stretegy as it play sto both our own strengths and Zope's strengths we think. So may question is was not: - "What comparisons should I have made 12-18 months ago?", but rather: - "What is presently the state of play in Zope vs. Other Alternatives ?" Moving targets beget moving questions And in the RealWorld(tm) I believe all targets move all the time, as do users, needs, and the alternatives..

Anyone else seeing the parallel to software mentioned in Douglas Adams' "Dirk Gently's Holistic Detective Agency"?

Sorry I don't know the reference, please enlighten me cheers - Jason

Completely calm and friendly opinions follow...

yes thanks..

I don't think it's any more difficult to create an attractive (graphics-wise) site in Zope than it is with PHP or ASP or plain old Apache-served HTML files. Quite honestly, I'm not qualified to do it with any tool. :-) I get the feeling that a lot of people expect Zope to design sites for them. Maybe they're expecting too much. Or maybe I'm expecting too little??? Or maybe it's that most of the people using Zope today (like me) are not pretty-site designers, but people that want a powerful tool to manage the most important part of a site...content.

I agree absolutely that Zope is on level with PHP, ASP apacheHTML in terms of ease. My point is that Zope allows one to create powerful highlevel functionality at many levels, wrapping, hiding, abstracting, reusing, modularizing things which potentially could allow graphic designers to jump in and do great work. But out of the box it does not and for perhaps cultural reasons will not..Zope is largely based on reusable templates, and chunks of 'smart-html' better known as DTML. What Manila has done is to provide some reasonable default templates for getting useful site development work done 'out of the box' - they have provided a structure template, and well defined access to changing the obvious things people want to change. Perhaps the only product which does for Zope is Squishdot.. and I think that largely explains why most Zope sites are Squishdot or modified squishdot sites. I do not believe it is content vs. style.. I really think it is a matter of Zope programmers working with graphics and web site interface designers to create some much more accessible site templates. I fear that without these Zope will be missing a great opportunity to extend itself into RealWorld web applications. It _has_ the capability but lacks the real benefits in the zope community 2-way dialogue between content managers and content presenters. The point of view is wonderful, but rather one sided.

Zope is not to blame for what people have done with it on the visual side. Content is far more important than visual appeal. I see too many companies (many of my clients) ignoring this and focusing way too much on layout, placement of images, colors, cute JavaScript menus and other fancy stuff. I'm not saying these things are not at all important. Browsing an unattractive, sloppily layed out site with lots of useful information is annoying and distracting. But it's *far* better than browsing a fancy, "attractive" site that has nothing to offer other than sparse information, pretty images and slow viewing time.

Yes and Yes. But be careful not to ignore the implications that the medium is [part of] the message. Style _is_ part of the content. Depends on who and what your audience is. In so far as websites are [virtual] places, the look and feel of the environment does matter. Where people get carried away to either extreme they will surely fall off those edges. The invisible server-side aspects of sites will only be visible as experienced functionality by end users. But the visible client-side is all they will ever touch. yin and yang. How they fit together is where the magic lies. It takes a diversity of talents and perspectives to make this work. Content not style is a great mantra - but it leads to content without style [and vice versa] and who wants that? I did not say it had to be complex or excessive.. Less is more and much harder to design often. The problem is that to achieve good minimal design requires a lot of iterations. People are looking for new interface paradigms and also better tools to allow them to find them, and subsequently explore them when they do. This means tools with the flexibility of zope but not in it its present state of awareness.

It's the site designers. Zope isn't designed for assistance in creating attractive sites. It's designed for creating manageable sites. It's completely up to the designers to make it attractive, using tools designed to do so. Zope (in my experience) does nothing to limit the ability to make a site attractive, but it does do buckets for increasing manageability.

Yes. I quite agree..But why are there no attractive Zope sites? My argument is that zope does nothing to HELP one's ability to make a site attractive. Actually it does limit one's ability. for example look at even the syntax for making an image object borderless? it aunt obvious.. and it could/should be part of the image object properties --or how about a rollover button.. Yes that is a JavaScript problem perhaps, but what about including that as a BASIC feature of modern websites. But imagine if that alone was made easier by zope. Navigation bar objects would be another big plus. Or how about a web page 'Table object' which made allowed one rapidly to group and include other zope object in a useful and productive way. This is not gratuitous graphics this is stuff which is common to most websites. All the HTML tools do this. In zope a designer [= end user content manager] needs to be able to work with higher level tools which function with acquisition just like standard_html_header etc. for example [ad hoc]: 1) Create a folder, some a sub folders and 'dummy' dtml documents. 2) Add a navigation bar creating basic links to the above. This would auto create a set of matching named methods 3) Add a style_object which would allow one to apply css or similar across the above. Again auto-create matching named methods in each folder to allow low level tuning to happen later 4) create a standard_table_object with named areas to allow population adn linking of HTML/DTML etc 5) Create standard_site_overview document which would link to the above, including standard_report_methods which would spit out the stats/properties on each part so you could see each section in a browser but also print out. As I understand it all the above is daily business in zope, using all manner of dtml-in and -with, sequence-item iterations etc. But just bundling and linking these would allow a lot more people to jump and get on with making great Zope sites. This is not reinventing Dreamweaver3. This is accepting that real world work on web sites post-1995 needs the above to be productive for designers to work well in these environments.

I'm comfortable that the zope.org developers will agree that their site is not the greatest thing on earth, esp. when it comes to prettiness. It is, however, consistent, easy to use, informative, and provides some nice real world examples of Zope's power. Using any of the already available calendar-like products for Zope, DC could easily create a calendar to browse through stuff. Again, it's not a limitation of Zope, the developers just didn't do it.

Yes and I am continuously curious why they did not? Again we can learn from Manila. When you create a Manila page it comes with instantly usable templates. Zope only does this for its own management screens which are invisible to end users. When you create a Folder in Zope it offers you -Create public interface -Create user folder And if you select yes you will get 'index_html' and 'acl_users' included.. THIS is the entry point I am talking about The 'Add a Folder' page needs to offer more so that it can default to the immediate bones of a useful site, methods and links. The irony to me is that such a feature would really show off Zope strengths and save a mountain of time. It would allow many other skilled people to jump in and do some great work .. Hell it would help create new work for zope programmers. People would pay for useful modules like this because they would save valuable time adn still leave the source open. best of both worlds.. could be loaded could as .zexp and off you go.. But because of the steep learning curve of ZopeDTML and resistance of Zope programmers to 'visual design' discussion.. they are short changing and ducking the real gain issue = 'project workflow' which is the backbone of content management.

Perhaps your use of External Methods is because you should not have been trying it in DTML in the first place. I have seen so many times DTML used for things it just wasn't designed to do. After all, it's not a programming language. External Methods, Python Methods, ZSQL Methods and all the other methods are there for a reason. To each its own purpose.

Yes this is true.

...

So may question is was not: - "What comparisons should I have made 12-18 months ago?", but rather: - "What is presently the state of play in Zope vs. Other Alternatives ?"

.. and the chart Nils pointed me to at http://www.camworld.com/cms/ is very good start It has some holes, but is in the right direction. I would love to see an interactive version on line at www.zope.org so people could add their opinions and expertise. I would love to hear from DC & Zopistas on this.

I rant about the powers of Zope while admittedly not knowing much about the alternatives for comparison. I do know, however, that Zope is powerful and has been loads of fun to work with.

yes SAME HERE :-) cheers - Jason

Ron yes +thanks for paying keen attention here..

...

What Manila has done is to provide some reasonable default templates for getting useful site development work done 'out of the box' - they have provided a structure template, and well defined access to changing the obvious things people want to change.

I see. Having higher level drop-in Web sites, IMO, is a job for add-on Zope products that could be created by DC or the community to meet various needs (as in Squishdot like projects). As the Zope community grows, I have no doubt that more add-on products for "Web sites in a can" will pop up.

Exactly. My concern is to get the right kind of discussion going because it is going to need some differnt kinds of minds to work together.

I can only guess that most Zope users are either not designers or are so filled with awe over its power that they forget to put effort into beauty. :-) I think Zope lends itself more to the programmer and content provider types, and leaves the designer with nothing special to desire. I don't say that in a bad way, but Zope isn't a design tool, so designers have no special interest in learning to use it. As Zope makes its way into more businesses with design teams, pretty design will make its way into more Zope sites.

Problem is am not sure Zopie will make its way into more businesses wiht design teams if it is such a pain in the $# to get sites sketched out. A really valuable feature which Zope could offer is Site-Sketching You do the back of napkin whiteboard 'design' of the main site architecture hierharchy functioning. Now you need to map it out in 'dummy' mode so everyone can get to work playing with it and working on the bits they are all best at. You know you are going to make changes and so you want to benfit from object abstraction from the get go You know in house team and design [visual + code] will force changes not to mention clients.. Then start throwing database at it - look and feel vs. satabase search menchaisms etc. This can be expensive time consumign stuff.. things people need to apply samrt reusable components to.. but which also allow them to get down very fingraoned and adjust = zope I think there is a big demand for this kind of up and running toolset. A zope folder full images or navigation widgets or search form elements are the type of things yu want to do a single copy paste or import on. I am a designer who has a special interest in learning to use. I do not see many other tools with this potential, but in its present state and my present programming skills, I am still a little short of being able to take Zope where I see it can go on my own. I hope this changes soon..

My understanding is that DC has been putting so much of their resources into the Zope core, much needed documentation, and probably their consulting business, that their own Web site has been left with a lower priority. I don't fault them for that. I think they've done a great job at prioritizing.

Granted. The price is right and there is some hairy stuff under the hood. I just hope DC can step back a bit more from time to time to see where they fit in from other perspectives also. I realize their income comes from consulting. They could apply their expertise [or others] to package off useful stuff for a reasonable price. Zope products coudl be very cost efefctive all around - those with teh time and skills can develope their own. Perhaos you are right adn it is still a little early yet.. maybe next year..

...

And if you select yes you will get 'index_html' and 'acl_users' included.. THIS is the entry point I am talking about The 'Add a Folder' page needs to offer more so that it can default to the immediate bones of a useful site, methods and links. The irony to

I think the "bones of a useful site" belong in a different object than a Folder, though I agree that specialized products/objects for canned sites would be a nice addition to the Zope products list, whether from DC or the community.

Yes. How about : - 'Add Bones object' - 'Add Navigation Object' - Add Styles object' - 'Add Report Object' - 'Add WebSite Object' Any one else interested to go further with this? kind regards - Jason

Exactly. My concern is to get the right kind of discussion going because it is going to need some differnt kinds of minds to work together.

This meshes with my thinking recently. I think many in the Zope community are "early-adopters" kind of people -- willing to put up with spending time to know the ins and outs of DTML or python programmers who would do most in python. A python programmer or early adopter does not a typical web design team make. Personally. I like the notion of a DTML an that you can do a little business logic there if you choose to. This issue with DTML in my mind is that its syntax/semantics design throws people for loops that can waste their time for sometimes days. Early adopters will go through this trial by fire. I did and now on the other side I know the gotchas. Early adopters are a special breed of people that will give a new product a ring of success but this pool saturates easily, leading a new company to the chasm.

Well put.

To cross the chasm, and reach a broader audience, this trial by fire phase of becoming a productive Zope user has to be reduced -- in addition to addressing other productivity parts of the bigger product pie mentioned in prior messages.

If you are interested in understanding the business of Crossing the Chasm, I would recommend a book by the same name. I think the Zope story is still unfolding on how an open source product will cross the chasm.

Regards, Albert Boulanger aboulanger@vPatch.com

Thanks for this. It looks interesting. Google came up with: http://www.testing.com/writings/reviews/moore-chasm.html http://www.mit.edu/people/wdc/chasm.html and a lot of other funny stuff I recommend Don Norman's "The Invisble Computer". It belongs on teh same shelf next to 'Crossing the Chasm'. regards - JASon

Jason Cunliffe wrote:

...

Completely calm and friendly opinions follow...

yes thanks..

...

I don't think it's any more difficult to create an attractive (graphics-wise) site in Zope than it is with PHP or ASP or plain old Apache-served HTML files. Quite honestly, I'm not qualified to do it with any tool. :-) I get the feeling that a lot of people expect Zope to design sites for them. Maybe they're expecting too much. Or maybe I'm expecting too little??? Or maybe it's that most of the people using Zope today (like me) are not pretty-site designers, but people that want a powerful tool to manage the most important part of a site...content.

I agree absolutely that Zope is on level with PHP, ASP apacheHTML in terms of ease. My point is that Zope allows one to create powerful highlevel functionality at many levels, wrapping, hiding, abstracting, reusing, modularizing things which potentially could allow graphic designers to jump in and do great work. But out of the box it does not and for perhaps cultural reasons will not..Zope is largely based on reusable templates, and chunks of 'smart-html' better known as DTML.

What Manila has done is to provide some reasonable default templates for getting useful site development work done 'out of the box' - they have provided a structure template, and well defined access to changing the obvious things people want to change.

Perhaps the only product which does for Zope is Squishdot.. and I think that largely explains why most Zope sites are Squishdot or modified squishdot sites.

Then you need to get out more ;) I have visited man, many zope sites, and only a few were squishdot based. ...

This means tools with the flexibility of zope but not in it its present state of awareness.

...

It's the site designers. Zope isn't designed for assistance in creating attractive sites. It's designed for creating manageable sites. It's completely up to the designers to make it attractive, using tools designed to do so. Zope (in my experience) does nothing to limit the ability to make a site attractive, but it does do buckets for increasing manageability.

Yes. I quite agree..But why are there no attractive Zope sites?

Maybe you just have an entriely different idea of attractive? I have seen several site I would classify as 'attractive'. I have seen sites that you wouldn't know were on a Zope server unless you noticed something like index_html in a link.

My argument is that zope does nothing to HELP one's ability to make a site attractive.

And others arew arguing that it should not. Apache does nothing to help the 'attractiveness' of a site, nor should it.

Actually it does limit one's ability. for example look at even the syntax for making an image object borderless? it aunt obvious.. and it could/should be part of the image object properties

None of my images have problems with that. border=0 is pretty damned easy.

--or how about a rollover button.. Yes that is a JavaScript problem perhaps, but what about including that as a BASIC feature of modern websites. But imagine if that alone was made easier by zope.

See the ActiveImage (?) product that does this.

Navigation bar objects would be another big plus. Or how about a web page 'Table object' which made allowed one rapidly to group and include other zope object in a useful and productive way.

There are, I beleive, at least two products that do this.

This is not gratuitous graphics this is stuff which is common to most websites. All the HTML tools do this.

Exactly. The HTML tools. That is where it belongs, not in a server.

In zope a designer [= end user content manager] needs to be able to work with higher level tools which function with acquisition just like standard_html_header etc.

for example [ad hoc]:

1) Create a folder, some a sub folders and 'dummy' dtml documents. 2) Add a navigation bar creating basic links to the above. This would auto create a set of matching named methods 3) Add a style_object which would allow one to apply css or similar across the above. Again auto-create matching named methods in each folder to allow low level tuning to happen later 4) create a standard_table_object with named areas to allow population adn linking of HTML/DTML etc 5) Create standard_site_overview document which would link to the above, including standard_report_methods which would spit out the stats/properties on each part so you could see each section in a browser but also print out.

As I understand it all the above is daily business in zope, using all manner of dtml-in and -with, sequence-item iterations etc. But just bundling and linking these would allow a lot more people to jump and get on with making great Zope sites.

This is not reinventing Dreamweaver3.

And none of this is something Zope prohibits. Do not confuse lack of IDE-type tools for editing HTMl with A Zope Server's features and functionality. You are describing things thout should be a function of the HTML editing tools, not the Server.

This is accepting that real world work on web sites post-1995 needs the above to be productive for designers to work well in these environments.

...

I'm comfortable that the zope.org developers will agree that their site is not the greatest thing on earth, esp. when it comes to prettiness. It is, however, consistent, easy to use, informative, and provides some nice real world examples of Zope's power. Using any of the already available calendar-like products for Zope, DC could easily create a calendar to browse through stuff. Again, it's not a limitation of Zope, the developers just didn't do it.

Yes and I am continuously curious why they did not?

Perhaps they simply don't share your views.

Again we can learn from Manila. When you create a Manila page it comes with instantly usable templates. Zope only does this for its own management screens which are invisible to end users.

When you create a Folder in Zope it offers you

-Create public interface -Create user folder

And if you select yes you will get 'index_html' and 'acl_users' included.. THIS is the entry point I am talking about The 'Add a Folder' page needs to offer more so that it can default to the immediate bones of a useful site, methods and links. The irony to me is that such a feature would really show off Zope strengths and save a mountain of time. It would allow many other skilled people to jump in and do some great work .. Hell it would help create new work for zope programmers.

Many have done work like this. Perhaps you should spend more time investigating the additional products available for zope before drawing down judgement that this doesn't exist.

People would pay for useful modules like this because they would save valuable time adn still leave the source open. best of both worlds.. could be loaded could as .zexp and off you go..

But because of the steep learning curve of ZopeDTML and resistance of Zope programmers to 'visual design' discussion.. they are short changing and ducking the real gain issue = 'project workflow' which is the backbone of content management.

Now you are mixing issues. project workflow is independant of graphical or visual design. Programmers write code, and others determine HTML appearences. Here is an idea. If you think you can design a better looking Zope.org, do so. Then tell everyone where it is, and let everyone comment on it. I, for example, find most of the zope.org site quite appealing. If you don;t think zope.org and any other zope sites are attractive you should open you horizons, and see that many sites based on zope are attractive, at least to others. To have an aopiniuon that other zope sites are unatractive, and to then apply that opinion to a claim that zope won't let you do that, or that the lack of 'attractiveness' (again, IYO), is a fault of zope is fallacious. -- Do not meddle in the affairs of sysadmins, for they are easy to annoy, and have the root password.