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