Search results

Products.ZScheduler-crontab-5.0.0-1.lbn25.noarch

External zope scheduling via crontab

Products.ZScheduler-multithreaded-5.0.0-1.lbn25.noarch

Internal zope scheduling via a dedicated timer thread with individual worker threads to run each event

Products.ZScheduler-threaded-5.0.0-1.lbn25.noarch

Internal zope scheduling via a dedicated timer thread. Each event is run in this thread.

Products.ZServerViews-0.2.0-1.lbn25.noarch

This Zope add-on product provides for easy configuration of ZServer Views. It was authored by Leonardo Rochael Almeida, and sponsored by OpenMultimedia. A ZServer View is a (supposedly) small and fast WSGI application that runs directly from within the ZServer thread (a.k.a. medusa thread). This means that a ZServer View will run even if all Zope worker-threads are busy handling other requests. It also means that if a ZServer View is not fast, then it is blocking the ZServer from handling incoming requests for all worker threads, so be mindful when using this product. ZServer Views are mostly useful for system monitoring tools, like DeadlockDebugger or Zope resource monitoring.

Products.ZSyncer-1.0.3-8.lbn25.noarch

ZSyncer is a project that allows live zope objects to be synchronized from one Zope to another without doing the tedious export / transfer / import dance. It is very easy to use. ZSyncer also allows you to see at a glance which objects are out-of-sync. ZSyncer also allows you to view a diff against the destination object, for many types of objects.

Products.Zelenium-1.0.3-2.lbn25.noarch

This product allows developers to create TTW Selenium test suites inside their Zope instance, in order to do browser-based functional testing of their site. You can add a 'Zuite' object at any location within your Zope site. It behaves as a standard ordered folder, with a couple of differences: - It's 'index_html' is the "TestRunner.html" view familiar from Selenium. - It derives the test suite (in the upper left corner iframe) from all OFS.Image.File objects whose names start with 'test'. You can use the OrderedFolder support to modify the order in which the test case files are run. - It provides a "Zip" action, which allows you to export the test suite, all test cases, and the supporting Selenium Javascript / CSS files as a single, self-contained zipfile. Adding Tests Tests are just 'File' instances whose names begin with 'test'. They should have a content type of 'text/html', and should contain a table which defines the steps which make up the test case. See http://selenium.thoughtworks.com/testrunner.html for documentation on the table structure and the Selenese language. Using Additional Metatypes as Test Cases On the "Properties" tab of your test suite, you can add / modify the list of meta_types which the suite will allow as test cases. Adding "Script (Python)", for instance, allows you to define test cases in PythonScripts. Nesting Test Suites Each test suite automatically includes the test cases of any suite it contains. You can take advantage of this feature to organize your test cases in a hierarchy, running them in separate segments, or all at once. Including Tests from the Filesystem Test suites now have a property, 'filesystem_path'; if set, the suite will recursively load testcases from files in / under the directory pointed to by that path. The list of files to be included is computed via the following rules: - If the directory contains a file, '.objects', it is presumed to contain a list of files to be included, one per line; only those files / subdirectories (if present) will be included. In this case, the test cases will be presented in the order indicated in the file, followed by any test cases from subdirectories. - Otherwise, if the suite's property, 'filename_glob' is non-empty, it will be expanded (via Python's 'glob.glob') to compute the list of filenames. The test cases will be presented in alphabetical order, followed by any test cases from subdirectories. - Otherwise, any file will be considered a testcase. The test cases will be presented in alphabetical order, followed by any test cases from subdirectories. Capturing Results from the Test Run Selenium has a feature which allows the testrunner to upload result data from an automated test run to the server. Invoke the test suite from your browser as usual, but append the query string '?auto=1', to the URL, e.g.:: http://localhost:8080/test_suite?auto=1 Selenium will run all test cases, and then upload its result data to the 'postResults' method of your suite. (Note that you no longer need the 'postResults' PythonScript in the root of your site, because the latest version of Selenium posts to that name relative to the test suite).

Products.ZopeVersionControl-1.1.4-1.lbn25.noarch

Zope Version Control for the Zope application server.

Products.Zpydoc-4.0.6-2.lbn25.noarch

Zpydoc reads and formats python docstrings and much other useful information to dynamically produce automatic documentation for python, Zope, and Plone modules. As of Verion 2.x.x, it supports Plone skins.

Products.basesyndication-1.0.0-2.lbn25.noarch

atom,rss etc feeds

Products.contentmigration-2.1.19-1.lbn25.noarch

This is a generic content migration framework, which should help you write your own content migrations. It has no UI and no value on its own, but makes it easy to write certain type of content migrations. This replaces the ATContentTypes migration framework, and provide three useful extensions: A CustomQueryWalker can be used to specify a more specific catalog query for a walker to use (e.g. which content to actually migrate). This can be used with any migrator. A BaseInlineMigrator is similar to BaseMigrator, but does not migrate by copying the old object to a temporary location, creating a new object and applying migration methods. Instead, migration methods are applied in-place. This simplifies the code significantly, because attributes, local roles etc. does not need to be copied over. Note that whereas BaseMigrator works in terms of self.old and self.new as the objects being migrated, BaseInlineMigrator only has a single object, stored in self.obj. This can be used with any walker. An extension of this class called FieldActionMigrator uses the action-based migration framework for Archetypes fields, found in field.py. Please refer to that file for full details, but briefly, you specify a list of attributes to migrate at the storage level, instructing the migrator whether to rename, transform, unset or change the storage for an attribute. Please see the docstrings in walker.py, migrator.py and field.py for full details. For examples, see tests/cmtc.py and tests/testATFieldMigration.py.