Modified items

All recently modified items, latest first.

python2-persistent-4.7.0-1.lbn25.x86_64: This package contains a generic persistence implementation for Python. It forms the core protocol for making objects interact transparently with a database such as python-ZODB3.

python-repoze-2.3-1.lbn25.py37.noarch: Python moduel for repoze

python-ZODB-5.6.0-1.lbn25.noarch: The ZODB package provides a set of tools for using the Zope Object Database (ZODB).

python-ZEO-5.2.2-1.lbn25.noarch: ZEO is a client-server system for sharing a single storage among many clients. When you use ZEO, the storage is opened in the ZEO server process. Client programs connect to this process using a ZEO ClientStorage. ZEO provides a consistent view of the database to all clients. The ZEO client and server communicate using a custom RPC protocol layered on top of TCP.

python-BTrees-4.6.0-1.lbn25.x86_64: This package contains a set of persistent object containers built around a modified BTree data structure. The trees are optimized for use inside ZODB's "optimistic concurrency" paradigm, and include explicit resolution of conflicts detected by that mechanism.

Products.PlacelessTranslationService-2.0.7-1.lbn25.noarch: What is PlacelessTranslationService? ------------------------------------ PTS is a way of internationalizing (i18n'ing) and localizing (l10n'ing) software for Zope 2. It's based on the files supported by the GNU gettext set of utilities. A good source of information and background reading is the gettext documentation: http://www.gnu.org/software/gettext/manual/ Using PlacelessTranslationService --------------------------------- PTS is used in the following steps: 1. i18n your software 2. Prepare a translation template 3. Prepare translations of the template 4. Install translations Each of these is explained below. 1. Internationalizing Your Software A good overview of this can be found at: http://www.upfrontsystems.co.za/Members/jean/mysite-i18n 2. Preparing a Translation Template A translation template is an empty Portable Object file as defined by the gettext standard with a special header block. The PO format is described in detail here: http://www.gnu.org/software/gettext/manual/html_node/gettext_9.html#SEC9 The header block is fairly self explanatory and can be seen in the sample.pot file included in this directory. All phrases in capitals, the language code, language name and (optionally) the content type and preferred encodings should be replaced with their correct values. There are several ways to prepare a PO template: -- By hand: This can be done by copying the blank.pot included in this directory, replacing the sample values as described above and and then manually adding msgid and empty msgstr pairs for each of the msgid's used in your software. -- Using i18ndude: i18ndude is a tool that is useful when all your software is in the form of ZPT's that are stored in files on the filesystem. It can be downloaded from: http://plone.org/products/i18ndude 3. Prepare Translations of the Template Preferably, find a translation company that can handle the gettext standards and send them your .pot file. They should send back .po files for the languages you require. If you're doing it yourself, copy the .pot file to a file on the name of the language you're translating to and with a .po extension. Then go through that file and fill in the msgstr sections. Finally, update all the metadata fields at the top of the file so they are correct for the translation you have just completed. At this point, you should have a .pot file and a collection of .po files. 4. Install Translations PTS will look in folders called 'i18n' for .po files to use as translations. These 'i18n' folders will be searched if they are in the INSTANCE_HOME or in the directories of any of the Products you have installed. Copy your .po files to a 'i18n' folder of your choice in one of these locations. Once that's done, restart Zope.

python2-wsgiutils-0.7.2-1.lbn25.noarch: WSGI Utils (Version 0.7.1) -- WSGI Utils are a package of standalone utility libraries that ease the development of simple WSGI programs. The functionality provided is limited at the moment, patches to add new features and address defects are most The following components are included please refer to the documentation for more details:wsgiServer - This module provides a very simple...

python2-transaction-3.0.1-1.lbn25.noarch: This package contains a generic transaction implementation for Python. It is mainly used by the ZODB, though.

collective.blueprint.dancing-0.1-1.lbn25.noarch: collective.dancing blueprints for collective.transmogrifier pipelines

collective.blueprint.base-1.0-1.lbn25.noarch: collective.blueprint.base Provides transmogrifier blueprint base classes and several useful blueprints... contents:: Table of Contents.. *doctest*Blueprint Base Classes The collective.blueprint.base package provides base classes for clear and easy transmogrifier blueprints.Changing Keys For blueprints that add or change keys in items, it can be very useful to make the keys used by the ...

collective.behavior.localregistry-1.0b2-1.lbn25.noarch: Dexterity behavior to add a local plone.app.registry for content types, it adds a local component with a layered proxy registry.

collective.behavior.localdiazo-1.0b3-1.lbn25.noarch: Dexterity behavior to enable a local Diazo theme. This package aims to make easier the creation of microsites on big web sites.

collective.beaker-1.0b3-3.lbn25.noarch: This package provides a means to configure the Beaker session management and caching framework for use within a Zope 2 (and Plone) environment. Ordinarily, Beaker is configured using WSGI middleware. However, Zope 2 does not (yet) run WSGI by default (unless you use repoze.zope2). This package provides an alternative configuration syntax, based in zope.conf.

collective.azipfele-1.1.1-1.lbn25.noarch: This is a basic module aiming to create ZIP files asynchronous. Even if it has some basic built in data-extractors, it is not meant as a out-of-the-box package, but for integrators and addon-product authors. Creating ZIP files in a request-response cycle may take a lot of time. With this package a zip job info is queued into a AMQP-Server (such as RabbitMQ). The ZIP file is created in a worker instance. After the file was created an event is fired. With it i.e. an e-mail notification can be send out. The state of the creation (pending, processing, finished) and the timestamps (queued, started, finished) are shared between worker and instance. The worker instance gets a jobinfo (dict) with global key settings (dict) and a list of fileinfos (list of dicts). Each fileinfo has at least a valid UUID of an content item. For each fileinfo in the list one file will be created. It adapts the content with the given UUID with collective.azipfele.interfaces import IZipContentExtractor using ZCA. If fileinfo contains an extractor (string) it uses a named adapter. The IZipContentExtractor takes on call the fileinfo and gloabl settings. it is expected to return a tuple of filename and the data to be stored in the zip with the filename. The returned filename can be a relative path as well.

collective.autorestart-0.2.0-3.lbn25.noarch: Automatically reload changed Python files - putting agility back to Plone development. collective.autorestart monitors Python .py files for changes and triggers a reload when you edit the files. This way you don't need to restart Plone server between your code edit runs. collective.autorestart uses plone.reload package to perform the actual code replacement. File system is monitored using inotify interface which is only available for Linux. The future versions will support other operating systems as long as somebody contributes the file system monitoring code or gives the author a new computer running operating system X. Features * Recursively detect changes in ZCML and Python files which are known to Zope * Automatically trigger reload when files are changed (saved) * Audio playback depending on whether the restart succeed or failed - you can go back to your files and you don't need to watch the terminal

collective.autopermission-1.0b2-1.lbn25.noarch: This package registers an event handler that initialises permissions on the fly. To use it, simply include its ZCML: <include package="collective.autopermission" /> Then, you can use the <permission /> ZCML statement to define a new type of permission, without also needing to make the permission "spring into existence" via ClassSecurityInfo or similar.

collective.amberjack.portlet-1.1-2.lbn25.noarch: collective.amberjack.portlet This package provides portlet for collective.amberjack package. Set up environment This package allows you to create portlets that contain tours. You can select the tours that can be display and choosen by an user on these portlet. So this package allows you to create sets of tours on Plone site.

collective.amberjack.plonetour-1.1-2.lbn25.noarch: Introduction This package allows you to create tours on your site, based on collective.amberjack.core. This package contains the first released tours: * Add and publish a Folder * Add and publish a Page * Add and publish a News Item * Add and publish an Event * Format a page using the visual editor * Create internal links * Create external links * Upload an image * Insert image on a page * Upload and link to a File * Using the Contents tab * Using the Display menu Others will be released soon. Add and publish a Folder This tutorial shows you how to create a new folder and then publish it. At the end of tour you can see a public folder in your Home. Add and publish a Page In this tutorial you learn how create a new page and then publish it. At the end of tour you'll create a new page and publish it on your Plone-powered website. This tutorial uses the folder that you created in a previous tour ("Add and publish a Folder"). Add and publish a News Item In this tutorial you learn how create a new news item and then publish it. At the end of tour you can see a public news item in your Home. This tutorial uses the folder that you created in one of previous tutorials ("Add and publish a Folder"). Add and publish an Event In this tutorial you learn how create a new event and then publish it. At the end of tour you can see a public event in your Home. This tutorial uses the folder that you created in one of previous tutorials ("Add and publish a Folder"). Format a page using the visual editor In this tutorial you will revisit a page that you created and learn how to format content on the page. This tutorial uses the folder and the page that you created in previous tutorials ("Add and publish a Folder" and "Add and publish a Page"). You will learn how to to apply bold, italics, text alignment, and paragraph styles to the page. Create internal links In this tour you learn how insert hyperlinks into a page. You will revisit a page that you created in the previous tutorial "Add and publish a Page". You learn how browse the content of your site and how create a hyperlink to any page, news item, event, image, file or other content type within your Plone site. Create external links In this tutorial you learn how to create link to other webpages, documents or resources online. This tutorial uses the Page that you created in previous tutorials "Add and publish a Page". You learn how find the external link icon and how make a preview, that lets you confirm that you have the correct webpage. Upload an image This tour shows how add a new image to folder that you created in one of previous tutorials ("Add and publish a Folder"). You will browse the content of your site and find the image file you want to place in Plone. Insert image on a page In this tutorial you learn how insert image into a page. You should have at least one image already from a previous tutorial "Upload an image". You will browse to the location of an image you would like to insert and choose Left alignment and a Size or change the 'alt' text for the image. Upload and link to a File In this tutorial you learn how upload to your site binary file such as a PDF, DOC, XLS, PPT, RTF or other file type and how create a link to the file to allow a site visitor to download the file. Using the Contents tab In this tutorial you learn how take a look at the Contents tab, that lets you browse the filesystem of your website and perform administrative tasks. The items you have been creating for previous tutorials will listed in the Contents view. You learn how change the order of contents within a folder, how make copies of a content item and how cut-and-paste. Using the Display menu In this tutorial you learn how change the way that the folders contained items will appear on the screen, using the Display drop-down menu. You will see the Summary view, Tabular View and Select default page.

collective.amberjack.core-1.1-2.lbn25.noarch: How to create new tour First of all you need to define the tour. Starting version 1.1 we are using configuration based style. A tour is a .cfg file. It has an amberjack main section which has two options: title and steps - this is where you define tour steps: [amberjack] steps = my_step1 my_step2 title = My first amberjack tour there are also available two blueprints: 1. Step a step section is defined by collective.amberjack.blueprints.step and has several options: * title * text * url - step url definition * xpath - xpath selector * xcontent - xcontent selector * microsteps - microsteps sections * validators - tales expression validation it looks like that: [my_step1] blueprint = collective.amberjack.blueprints.step title = This is my first Step text = You should now know how to create a step section url = /mystep validators = python: context.isFolderish() xpath = '' xcontent = '' microsteps = microstep_1 microstep_2 2. Microstep a microstep section is defined by collective.amberjack.blueprints.microsteps and it has several options: * idstep * text * description * selector it looks like that: [microstep_1] blueprint = collective.amberjack.blueprints.microstep idstep = menu_state text = This is my dummy microstep description = Now you should now how to define microsteps selector = #insert Tour registration Finally you have to register it. The only acceptable format is an archive (zip or tar) which contains one or multiple .cfg files (tours) Using zcml: <configure xmlns:collective.amberjack="http://namespaces.plone.org/collective.amberjack.core"> <collective.amberjack:tour tourlocation="mytourpackage.zip" /> </configure>

python-munin.zope-2.1-4.lbn25.noarch: Introduction ------------ This package provides munin plugins for monitoring various aspects of a Zope instance. It uses `gocept.munin`_ for plugin registration. Please refer to its documentation if you want to write new plugins. Bits of the code is based on plugins found at `munin exchange`_ (many thanks to Gaute Amundsen and Arthur Lutz). Plugins ------- Currently there are 4 plugins available: * "zopethreads" - reports free Zope threads * "zopecache" - reports database cache parameters * "zodbactivity" - reports ZODB activity * "zopememory" - reports Zope memory usage (only works on Linux) How to use it ------------- * First include the package in your buildout `instance` slot:: [instance] ... eggs = ... munin.zope zcml = ... munin.zope * To create the pluging helper script you'll also need to include the following, additional section and extend your `parts` definition:: [buildout] parts = ... munin [munin] recipe = zc.recipe.egg eggs = munin.zope arguments = http_address='${instance:http-address}', user='${instance:user}' The `arguments` option is used to pass configuration values to the generated helper script, which is then used as the actual munin plugin (see below). Any settings for `ip-address`, `http-address`, `port-base` and `user` given in the `instance` section should be repeated here, separated by commas. .. |---| unicode:: U+2014 .. em dash Please be aware, that the variable names use underscores instead of dashes here |---| the following list shows all supported settings and their respective default values: * ip_address='<ip-address>' ['localhost'] * http_address=<http-address> [8080] * port_base=<port-base> [0] * user=<user-credentials> [n.a.] Either literal values or references to the `instance` part can be used here, i.e. "http_address='${instance:http-address}', user='${instance:user}'". Please note that the resulting line will be verbosely copied into the generated `bin/munin` script, so the extra quoting is required. * When monitoring more than one Zope instance, i.e. in a ZEO setup, separate helper scripts need to be generated. In order to do so the `scripts` option of `zc.recipe.egg` can be used like so:: [buildout] parts = ... munin1 munin2 [munin1] recipe = zc.recipe.egg eggs = munin.zope scripts = munin=munin1 arguments = http_address='${instance1:http-address}', user='${instance1:user}' [munin2] recipe = zc.recipe.egg eggs = munin.zope scripts = munin=munin2 arguments = http_address='${instance2:http-address}', user='${instance2:user}' The necessary symlinks can then be created with each of the scripts in turn (see below). Please note, that in this case you should explicitly provide at least a differing `prefix` argument. * Now you should be able to call the plugins as follow:: http://localhost:8080/@@munin.zope.plugins/zopethreads Where `zopethreads` is you plugin name. Please note that for security reasons the view requires the `View management screens` permission. * Next you need to make symlinks from the helper script inside your buildout's `bin/` to the munin plugin directory. The helper script itself can assist you with this:: $ bin/munin install /opt/munin/etc/plugins [<prefix>] [<suffix>] This will install the necessary symlinks in the given directory using either the provided prefix and suffix or else the hostname and current directory to assemble their names (see below). Alternatively, you may also install the desired symlinks yourself:: $ cd /opt/munin/etc/plugins $ ln -s ~/zope/bin/munin company_zodbactivity_site1 Here `/opt/munin/etc/plugins` is your munin directory, `~/zope/` is the root directory of your buildout, `zodb_activity` the name of the plugin you want to enable, `company` a placeholder for an arbitrary prefix and `site1` the name which will be shown in munin. * Finally configure the plugin in munin (this step can be skipped if you have correctly set up the `arguments` option as described in step 2 above):: $ cd /opt/munin/etc/plugin-conf.d/ $ vi munin.zope.conf ... [company_*_site1] ... env.AUTH myuser:myuser ... env.URL http://localhost:8080/@@munin.zope.plugins/%s Here `myuser:myuser` are your Zope user credentials and `localhost:8080` your site url. Please check `munin`_ for more information about plugin configuration.

« Previous 20 items Next 20 items » 1 ... 630 631 632 633 634 635 636 ... 2449


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

Sections

Modified items