My apologies in advance if I causing frustration. > On Saturday 14 January 2006 11:51, David Johnson wrote: > > The documentation is not well defined, which makes deployment dangerous > > because one may produce an application that does not conform to future > > releases of Zope. > > I have absolutely no idea what you are talking about. A lot of the > packages in > Zope 3 have text documentation files that define the API very well. > Furthermore, the interfaces document the API on a programming level. Tools > like API doc pull a lot of this information (and much more) together. > Other > than that, there are many beginner tutorials out there now and we have 2 > books. I have been unable to find any significant Zope 3 documentation on techniques for interface with SQL as was present in Zope 2. I have had other users respond privately with similar statements. Your book, while excellent, does not discuss the subject at all. I know Zope can handle these things, and I can setup a database adapter and create SQL scripts. However, what is the best way to integrate these into an application? I could make it work, I'm sure, but I fear doing so will make cause my application to break during a Zope upgrade or may not scale well. I have not been able to find any Zope 3 tutorials other than your Message Board application. Ditto web based user management.
I installed a Zope 3 application and the Zope server would not start because the interface specifications had changed since it was released, only 2 years ago to point where it was broken. They may have coded things incorrectly, but people will do that and they will make mistakes. > First of all, if you break any configuration file, not just Zope's, an > application will not start. Note that someone should never mess with the > ZCML > files directly. Use overrides.zcml to make your customizations. I disagree. We run a variety of applications and the most complex configuration files we have are in Apache, Nagios, and Exim; which surprisingly are the least complex applications we run. All of them offer configuration file testers, which are extremely good about pinpointing specific errors. Not to mention that all are relatively widely used and docs are easy to find. The Zope 2 configuration for example is not as difficult. Java based applications are the only ones I know that have complex configurations. Our company deploys very complex financial based transactions systems we have only a handful of about 10 very small config files which just contain database connection strings. We installed your Message Board application for example (step13), and the server would not start. I was unclear why (I think it had to do with the smileys). I probably could have figured it out, but there were some configuration files that required change, such as adding a file to ../etc/package-includes - but I'm a pretty experienced user and engineer. It does require some configuration. > > As to the production system, if you change configuration on a life > production > system, you are plain stupid. Also, the system administrator should > *never* > mess with ZCML. ZCML is application developer domain, not system > administration. > Also, I don't understand why a crashed server would cause anyone to mess > with > ZCML on a production system. I sincerely have no clue how you came up with > this. People are just plain stupid. Unfortunately it's a reality. We have high end clients we have to pamper (you work for one we're trying to get to at the moment), and we have to accept blame for their breakages if we want them to keep paying us. ZCML files look like configuration files and so they get played with when people get frustrated confused or just want to check on things. We just installed the MySQL adapater, and it requires adjustments to etc/package-includes. If I asked my system admin to install the Message Board application, step13, he would get an error because the smileys are missing. I can almost guarantee he would play with the ".zcml" files as a natural first step to diagnose the problem. He is very bright. For example, just the other day we had a system administrator edit a configuration file, and through some VI keystrokes during exiting, he managed to replace the first half of the file with an asterisk, and he didn't notice. The application continued to run, and restart without problems(BTW) despite missing half it's config. We only picked it up through a monitoring tool we have and security tools we have. In a moment of crisis, one wants an application that has a high tolerance for errors and problems. In regards to system crashes, lots of strange things can happen, and files can get corrupted. It is not as simple as re-installing or restoring from backup, if you think all the files are intact. A corruption error can cause a subtle yet important change in another wise apparently normal looking file. Or some error someplace else could manifest itself in Zope. In these situations, you want to have applications that report to you where there are errors and where to focus on fixing them. The files can be restored or repaired as necessary. Currently an error in Zope produces a long laundry list of files, and errors that are vague and "line" numbers that appear to be fractions (such as 11.7-11.41). I would vote for zero config files if it were a choice. > Aehm, not every application Zope 3 is used in is a public project. Here > are > other applications that have been deployed: > > - Zope Corp. Document Management System (closed) > - Tiks, a CMS for Zope 3 [a fairly large Web site has been in production > using > Tiks] (open) > - Another large document management application, which I do not know the > name > of > - Launchpad and other Ubuntu-related software > - SchoolTool/SchoolBell; I know that SchoolBell is used in several schools > and > universities around the world. > > These are some of the pure Zope 3 projects I know about; there are surely > many > that use Five. It is helpful to know these are out there. Thanks. Do you know of any mission critical Zope 3 applications yet? eBay, Amazon, grade? We plan on producing a virtual bank with distributed transaction processing around the globe and variety of interfaces to third party financial processors and legacy systems. I think we're going to go forward with Zope 3, but I am nervous. > If people do not report API breakage, then we cannot fix it. I tried very > hard to provide good backward-compatibility, but it's not an easy task and > problems are expected. I agree, and maybe this is the result of this project being relatively new. Hopefully I might be able to assist. > > Even the current i18n facility does not seem to > > work properly, editing messages frequently gives errors and does not > update > > properly. > SchoolTool uses the i18n facilities heavily and we have never had update > problems. Are you sure you know how GNU gettext works properly? I followed the documentation straight out of your book on this one, using IE. I have general trouble adding and editing messages. I do not know about GNU gettext. Procedure: 1. Add translation domain 2. Click on Translate view 3. Try to add messages (Messages do not get added) > > Errors in general seem to give unexplainable results. > > Could you give examples? I just installed the MySQL adapter, and I try to create a connection, and I make an error (bad username or something). Instead of an error, I receive "The page cannot be displayed"; I need to hit back to get back to ZMI. It works, but it's a bit odd. I can check the error log to find out why. It just makes think that things are not well thought out or that application development is rushed. > You have to be much more specific to provide constructive feedback. If you > are > unhappy with some part of the architecture, make a proposal or at least > bring > it up on zope3-dev. I agree, and *HOPE* to do so. Thanks again for your kind and polite dialogue. _______________________________________________ Zope3-users mailing list Zope3email@example.com http://mail.zope.org/mailman/listinfo/zope3-users