October 2007 - Zope - Zope lists

RE: value problem in textarea and input
by cristopher pierson ewing 03 Oct '07

03 Oct '07

Hamzat, could your problem be because the textarea html tag doesn't have a 'value' attribute? The value of a textarea input is the content of the tag. Perhaps change 'tal:attribute="value here/something|nothing"' to 'tal:content="here/something|nothing"' or the like? C ******************************** Cris Ewing Department of Radiology Web Services University of Washington School of Medicine Work Phone: (206) 598-8706 Home Phone: (206) 365-3413 E-mail: cewing(a)u.washington.edu *******************************

1 0

value problem in textarea and input
by kamal hamzat 03 Oct '07

03 Oct '07

Dear All, I am having problem when using <input> and <textarea> <input type="text" name="summary" size="40" value="#" tal:attributes="value here/summary|nothing" /> when i submitted the form and loaded it back the summary shown in the input tag, may be because "value" is part of input attributes. <textarea name="summary" size="40" tal:attributes="value here/summary|nothing"> </textarea> But when I use the textarea tag as above, submitted the form and loaded it back the summary was not showing. Thanks. Kamal

2 1

[WARNING] Garbage collection may be disruptive
by Dieter Maurer 03 Oct '07

03 Oct '07

We currently face a strange problem in a high performance Zope setup. Its features are special such that not all of you may fear to face the same problem: The setup consists of a large number of Zope instances all talking to a ZEO. Almost every non-trivial request (all requests not delivering static content) write to the ZODB. This means, we are using the ZODB in a high frequency write szenario -- one, it has not been designed for. The problem: ZEO reports large amounts of "client blocked" occurrencies *BUT* neither the IO nor the CPU on the ZEO host is utilized significantly. This implies that it is not ZEO which is the bottleneck but the ZEO clients. Up to yesterday, I was extremely puzzled by the behaviour of the ZEO clients (i.e. the Zope processes). Usually, they worked quick and reliably but occasionally, everything and especially the IO seemed extremely slow. I added log messages to prominent IO operations and could (e.g.) see occational times for "stat" in the order of 5 to 20 s. The system is complex and there are many possible causes for such desastrous behaviour. One may be problems with the IO subsystem. Our administrators told me they could not see any unusual load on the IO subsystem. But, for them, too, the system is complex. I knew that the strange timings could mean two things: the IO is really that slow or the measurement is flawed. But all measurements went into the same direction. But all measurements used Python.... And this could mean that the Python thread scheduling (controlled by the GIL) is extremely distorted -- distorted in the order of 10 to 20 s. Yesterday (far too late), I decided to prove whether or not there are scheduling distortions. I put another thread in the Zope processes, scheduled periodically, which complains when there is too much discrepancy between the expected and the observed scheduling time. The thread proved: there are scheduling distortions at least in the order of 5 s. Next question: why? This morning I found a candidate: Python's garbage collector. Of course, it holds the GIL (and prevents Python thread scheduling) while it runs. From the documentation, I had the impression that it should be efficient and quick, even for full (generation 2) garbage collections -- but who knows. I disabled automatic garbage collection and replaced it with a peridic call to "gc.collect", logging the executions times. The times started with 0.6s but meanwhile increased to 1.9 s per run and I expect they will easily grow further until 5 to 6 s per run.... Moreover, scheduling distortions are reported precisely when the garbage collector runs... Usually, occasional garbage collection times of 5 to 6 s are not so problematic -- provided that they are not so frequent that they severely interfere with transaction commits. In our case, they do interfere with transaction commits and can severely slow down the complete ZEO client farm due to contention for the commit lock. The reason is a broken TextIndex implementation -- again maybe special for our installation. The aim of this message: should you see strangely behaving ZEO clients and lots of unexplainable "clients blocked" in your ZEO logfile, you may think of scheduling distortions caused by Python's garbage collector. -- Dieter

2 2

Problems with my ZMI
by Ken Winter 02 Oct '07

02 Oct '07

A year or so after installing this installation of Zope, I'm suddenly having trouble opening Python Scripts and Page Templates for editing in my ZMI. (Zope 2.9.6-final, python 2.4.3, win32.) Specifically: 1. When I click on the name of a script, I get this message: Site error This site encountered an error trying to fulfill your request. The errors were: Error Type IndexError Error Value string index out of range Request made at 2007/09/27 17:06:33.640 GMT-4 2. When I click on the name of a Template, the template's Edit tab opens, but the field containing the template body is shrunk to its minimal size (3 rows high x a few characters wide). An attempt to fix this by hitting (for example) the "Wider" button evokes: Site error This site encountered an error trying to fulfill your request. The errors were: Error Type ValueError Error Value invalid literal for int(): Request made at 2007/09/27 17:11:33.375 GMT-4 Restarting Zope doesn't help. Any fix for this? (Preferably a fix that don't involve reinstalling Zope and everything else built upon it.) In the meantime, any workarounds that will enable me to edit my objects? ~ TIA ~ Ken

3 4

ANN: z3c.recipe.egg - Recipes based on zc.recipe.egg for working with source distributions
by Ross Patterson 01 Oct '07

01 Oct '07

I just bundled up and released some zc.buildout recipes I've found useful. Attached is the README.txt. http://cheeseshop.python.org/pypi/z3c.recipe.egg Ross ============== z3c.recipe.egg ============== Recipes based on zc.recipe.egg for working with source distributions. Editable Distributions ---------------------- The z3c.recipe.egg:editable recipe uses the easy_install --editable and --build-directory options to download multiple source distributions. The source distributions will be placed in the part directory and managed by the buildout if build-directory is not specified. If so, the distributions will be replaced when newer versions are available. So be sure to set build-directory to a directory not managed by buildout if you want to maintain changes to the source distributions. The z3c.recipe.egg:editable can be used to assemble a set of subversion checkouts to work with specifying subversion URLs in find-links as is supported by easy_install. See the easy_install documentation for the syntax for using subversion URLs. There are a number of ways in which it is more flexible to control checkouts via recipes rather than svn:externals. Finally, if the develop option is true then the distributions will be installed in develop mode. See z3c/recipe/egg/editable.txt for more details. Running Setup Scripts --------------------- The z3c.recipe.egg:setup recipe calls arbitrary setup.py commands on multiple distributions in a buildout. The z3c.recipe.egg:setup recipe can be used, for example, to automate releases. When the source is ready for release, the setup recipe is configured to run the "register sdist bdist_egg upload" setup commands. To ensure release only runs when intended, the setup recipe can be used in it's own release.cfg file that extends the buildout.cfg file. With this setup, releases for multiple projects can be made with "bin/buildout -c release.cfg". The z3c.recipe.egg:setup recipe also supports the develop option as with z3c.recipe.egg:editable. See z3c/recipe/egg/setup.txt for more details.

1 0

tunneling via ...
by David Bear 01 Oct '07

01 Oct '07

I am in a situation will I may soon need to outsource the running of my apache server. This may be a good thing. However, I cannot outsource the running of my zope server. So I have the situation where apache will be running on a separate box from my zope server and I am wondering how to make sure I have a secure connection between the apache server that I don't control that will be using modproxy/rewrite rules to get content out of my zope server. Currently, zope only binds to 127.0.0.1 and apacy proxy connects. Using a remote apache server implies that I will need to have zope listen on a public interface. However, I will still need to secure it so I was considering openssl or something like that. in short I have APACHE HOST <------------------> ZOPE HOST I need to secure the connection between these two hosts. Any recommendations? -- David Bear phone: 602-496-0424 fax: 602-496-0955 College of Public Programs/ASU University Center Rm 622 411 N Central Phoenix, AZ 85007-0685 "Beware the IP portfolio, everyone will be suspect of trespassing"

4 3

Re: [Zope] Upload to database from a table (fwd)
by Andreas Jung 01 Oct '07

01 Oct '07

Please stay on the list! -aj ------------ Forwarded Message ------------ Date: 1. Oktober 2007 17:58:06 +1200 From: Inspire <maxw(a)inspire.net.nz> To: Andreas Jung <lists(a)zopyx.com> Subject: Re: [Zope] Upload to database from a table Thanks for the response Andreas You are correct in that my understanding of Zope is rather shallow! More to the point as to what I am attempting to do: What I have done with Paradox and do not know how to duplicate with Zope is to place three editable fields on a form (Date, Person and Account) and a table that lists the store inventory. The store inventory is downloaded from Postgres each time the form is accessed, and is sorted (type, item). This info is displayed on the table as well as the item store number which is hidden from view or rather is in the underlying table. On the table is also an editable field to enter the quantity of goods issued. Paradox makes it a simple matter to filter the displayed info by type, or to search for the required item to locate it and enter the issued goods. The great benefit of using Zope is of course the access levels that can be set up. The site is to cover Safety, Quality and the store. The organisations owner/manager can from a browser, access the information he wants. Supplying him and others with the information from Zope, is of course relatively straight forward - it is the input forms that have me. Once I have got this one going the rest should be straight forward. As both Paradox and Python have a common root in Pascal I have not found too much difficulty in writing code in either. Some help will be much appreciated regards Max On Monday 01 October 2007 06:03, Andreas Jung wrote: > --On 1. Oktober 2007 05:52:07 +1200 Inspire <maxw(a)inspire.net.nz> wrote: > > To update one entry into the database from the browser is > > straight-forward. > > Huh? You can of course as much SQL statements within one Zodb request as > you like. Why should this be limited to only one update?? > > > I have not worked out how to enter multiple > > transaction yet. > > There is usually no need to deal with transactions on your own. Most > database adapters abort/commit together with a ZODB abort/commit. The > transactional integrity is given. > > > It is probably pushing the boundary of Zope, > > Unlikely your pushing the boundary...obviously you need a deeper > understanding of Zope....at least your posting does not contain much > valuable informations about what you are really trying to achieve and how > you are trying it to achieve...another try...explain what you're trying to > do and how. > > -aj ---------- End Forwarded Message ---------- -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info(a)zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting

1 0