Am Mon, 2002-09-09 um 11.21 schrieb Newbie:
Hi,
can someone give me some ideas on what Zope can be useful for small scale website? I understand zope as a good platform to build web application (medium to large scale) and portal solution. But if I have only 20 pages of websites and news I probably update only once a week, is Zope still useful? Well, there are certain pluses, like being able to generate the website dynamically. And this includes automatically correct intrasite links, content-management, etc.
To use Zope, I still need to understand HTML if I create the content using DTML document. One of the good advantage its ZMI. But not everyone understand HTML well and ZMI might not be a good tools to update one's website. Well, yes and no. For usual text oriented documents Structured Texts seems to be sufficient.
There are a lot of website builder such as Frontpage. With frontpage, one can manage his/her website locally, update it and synchronize the contentt with the server. Well, Frontpage is a bit like a NISSAN 300ZX. Nice to look on. At least as long as you do not intrude into the technical details below the skin, ...
Could anyone just give me idea why would I prefer to use Zope for small scale website?
From $ standpoint, zope hosting is more expensive than other frontpage, php hosting (of course for small scale site)
Well, this is certainly true, because Zope is hosted not by "uploading precalculated .html pages", but by dynamically calculating these upon request. Things that are rather trivial with Zope, and which are not possible with this "static pages" modell: - Talkback sections - including actual data like * references to the current time (like in "this was posted 16 hours ago") * count of active sessions ("there are x Users and y Guests online") * references to the current user ("You are coming from 10.11.12.13" or changing the page view upon the pages viewed before: "News Items (X items not shown which you have already seen:") * creating different views of your content depending upon the User Client. For example different styles of CSS or a text only version for certain clients like lynx, Search-Engine-Crawlers, .. - calculate dynamically the navigation. * Zope.org download area is known to use ZCatalog searches just to generate the lists of Products. * Workflow (just put some properties like "published" or "published_on" on your Data items) Well, yes you can probably stick with static publishing for your projects. (small + once a week updates) But should the project ever grow (in size or in features) you will have these options: 1 add the dynamic features via "cgi" scripts. (or .ASP, .php, .jsp) 2 switch to Zope. 3 switch to some prefabricated Content Management System. 2+3 have some common drawbacks and advantages: - you will need to rework your whole content to fit the organization of the CMS. - you need probably to have hosting account that allows for running CGIs or even long-running CGIs + more professional feel of the site. (Actually this refers to the technical side, the look is still depending upon the HTML you produce ;) ) 3 compared to 2 has the additional problems that: - it's usually more rigid. With Zope you write your site as dynamic or as static you like. - While there are free CMS beside Zope, there is a number of quite expensive CMS options. 1's disadvantages and advantages: + works with most "pay-for" webhosters. - difficult to customize. - you get a completely non-homogen mixture of technology. (Your Guestbook remembers the User data via a different set of cookies than your talkback section, etc.) - you usually need some kind of database. Or you have CGI that store data that belongs into an ACID storage in the filesystem. 2's list: + ZODB (Zope Object Database) is the ultimate in safe data storage. [Actually I've tried to track any ZODB troubles by looking at the mailing lists, and while I've found some issues, they were nothing to write home about. Probably safer to your data than any other open source data storage. And the safety of closed source big iron databases is difficult to guess as they are not only closed source, but usually also closed bug tracking, ...] - steep learning curve. + Python. + cross platform. (Host it on Linux system, develop on Windows, whatever) + ZEO (clustering solution) + open source. + easy integration with SQL databases. So depending upon your needs and your own set of prejudices (I'm on the free software side. So Frontpage is not really a contender IMHO), Zope might be what you need or not. ad Performance: I can only give anectodal evidence because I haven't yet tried to do more scientific benchmarking. 4 different hosts: a) 486DX4/75, 24MB RAM, 4GB old non-dma harddisc b) Vaio FX201, Duron 700, 512MB RAM, 10GB laptop dma IDE c) Thunderbird 900, 768MB RAM, dma IDE d) Celeron 600, 128MB RAM, dma IDE (older) [small webhosting server] Zope 2.5.1 (ZServer) on a) with the standard page (which does minimal dynamic things like including header and footer) seems to be able to give about 3-4 requests per second. Zope 2.6.0a1 (ZServer) on b) with some dynamic page (objectValues enumeration, etc.) get's into about 30-35 requests per second. Zope 2.5.1 (Apache/PCGI) on d) gets about 10-20 requests /s for some pages containing dynamic navigation and Structured Documents. (This site is also visible from the outside and an example for some really simple small site: www.detox.at) Quixote with a dynamic page (os.listdir+os.stat) and a pure CGI adapter (Apache) on c) gives about 3 requests per second. This is only as a reference for the performance of "typical" CGI applications. A static page on c) gets about 100 requests/s. So to summerize: Usually Zope is much faster than CGI applications. (about 10x) (Well it's probably a bit more, because the b/c hardware is not exactly the same.) CGI on my setup is about 33x slower than static pages. Zope is about 3x slower than completely static pages. Zope can run acceptably on very minimalistic hardware. Andreas