Modified items

All recently modified items, latest first.

Products.kupu-1.5.2-1.lbn13.noarch: Kupu is a cross-browser WYWSIWYG editor. It allows the comfortable editing of the body of an HTML document. It's client-side (browser) requirements are one of: - Mozilla 1.3.1 or higher - Internet Explorer 5.5 or higher - Netscape Navigator 7.1 or higher - Opera 9 or higher Server-side there are hardly any requirements, except for some way of processing data (CGI or something more fancy like PHP, ASP or Python scripts in Zope). Kupu is particularly suited for content migration as well as editing. Content copied from an existing web page is pasted with all formatting intact. This includes structure such as headings and lists, plus links, image references, text styling, and other aspects. Copying text from a word processor with an HTML clipboard - such as MS Word - works exactly the same. Kupu will clean up the content before it is sent to the server, and can send data to the server asynchronously using PUT (which allows the data to be saved without reloading the page) as well as in a form. Kupu can be customized on many different levels, allowing a lot of changes from CSS, but also providing a JavaScript extension API.

Products.jsImagePopups-2.0b6-1.lbn13.noarch: Provides lightbox functionality for images

Products.i18ntestcase-1.3-1.lbn13.noarch: Products.i18ntestcase is build on top of the ZopeTestCase package. It has been developed to simplify testing of gettext i18n files for Zope products. (c) 2005-2008, Hanno Schlichting (plone@hannosch.info) License: GPL Products.i18ntestcase Readme Products.i18ntestcase is build on top of the ZopeTestCase package. It has been developed to simplify testing of gettext i18n files for Zope products. The Products.i18ntestcase package provides: * The class 'I18NTestCase' of which you can derive your own test cases. * The classes 'PoTestCase.py' and 'PotTestCase.py' which include a set of common tests for po and pot files. * The 'test_i18n.py' script, which you can put in your tests folder to easily use all these already written tests. Copying the test_i18n.py to your tests folder is the preferred way.

Products.feedfeeder-2.1-1.lbn13.noarch: Feedfeeder has just a few things it needs to do: * Read in a few ATOM feeds (not too many). * Create FeedFeederItems out of the entries pulled from the ATOM feeds. Any feed items that contain enclosures will have the enclosures pulled down and added as File items to the feed item. * This means figuring out which items are new, which also means having a good ID generating mechanism.

Products.fatsyndication-1.0.1-7.lbn13.noarch: Five/AT layer for syndication

Products.contentmigration-2.1.5-1.lbn13.noarch: A generic content migration framework for Plone.

Products.basesyndication-1.0.0-2.lbn13.noarch: atom,rss etc feeds

Products.Zpydoc-4.0.5-1.lbn13.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.ZopeVersionControl-1.1.3-2.lbn13.noarch

Products.Zelenium-1.0.3-2.lbn13.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.ZSyncer-1.0.3-7.lbn13.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.ZScheduler-threaded-4.2.3-2.lbn13.noarch: Internal zope scheduling via a dedicated timer thread. Each event is run in this thread.

Products.ZScheduler-multithreaded-4.2.3-2.lbn13.noarch: Internal zope scheduling via a dedicated timer thread with individual worker threads to run each event

Products.ZScheduler-crontab-4.2.3-2.lbn13.noarch: External zope scheduling via crontab

Products.ZScheduler-4.2.3-2.lbn13.noarch: Zope Event Scheduler

Products.ZSQLMethods-2.13.4-3.lbn13.noarch: SQL method support for Zope 2.

Products.ZPsycopgDA-2.0.8-2.lbn13.noarch: PostgreSQL data connector for Zope

Products.ZChecker-20070819-4.lbn13.noarch: Check Zope Page Templates for correctness and XHTML-compliance

Products.ZCatalog-3.0.1-1.lbn13.noarch: Zope 2's indexing and search solution.

Products.ZCTextIndex-2.13.5-1.lbn13.x86_64: This distribution contains a full text indexing facility for Zope 2 and more specifically for Products.ZCatalog.

« Previous 20 items Next 20 items » 1 ... 2321 2322 2323 2324 2325 2326 2327 ... 2359


	Copyright © 2000-2024 Corporation of Balclutha Inc. All rights reserved.

Sections

Modified items