Modified items

All recently modified items, latest first.

plone.app.content-2.1.3-1.lbn13.noarch: plone.app.content contains various views for Plone, such as folder_contents, as well as general content infrastructure, such as base classes and name choosers.

plone.app.collection-1.0.11-1.lbn13.noarch: plone.app.collection

plone.app.changeownership-0.3-3.lbn13.noarch: Introduction plone.app.changeownership as it sounds is a plone package to change objects ownership. Problem There is no way in plone to transfer ownership of all objects owned by an user to a new user. To delete a plone member in such case is not an option. Solution plone.app.changeownership makes easy to transfer ownership from one ore more members to a new member. It also can change content metadata, like Creators field.

plone.app.celery-1.0-3.lbn13.noarch: This package integrates the `Celery` distributed task queue into Plone. It allows you to configure Celery from your zope.conf configuration file, and make sending task messages honor the Zope transaction manager. Configuration ============= You can provide Celery configuration via the Zope configuration file. Here is an example:: %import plone.app.celery <celery-config celery> server-email no-reply@vandelay.com admins George Costanza, george@vandelay.com admins Cosmo Kramer, kosmo@vandelay.com <broker> host localhost port 5672 user guest password guest vhost / </broker> <celery> ignore-result true disable-rate-limits true task-publish-retry true <task-publish-retry-policy> max-retries 5 interval-start 0 interval-step 1 interval-max 0.5 </task-publish-retry-policy> default-queue default <queues> default dict(binding_key='default', exchange='default') feeds dict(binding_key='feeds', exchange='feeds') </queues> <routes> feed.tasks.import_feed dict(queue='feeds') images.compress image.compression.Compress </routes> </celery> </celery-config> You must use the `%import plone.app.celery` statement to import the Celery configuration schema. The top-level section always is called `<celery-config>` and that section must have a name (due to zope.conf limitations), but it's name is otherwise ignored. The Celery configuration is subdivided into namespaced sub-sections. Each Celery configuration key (as defined in the `Celery configuration documentation`_) consists of a namespace (such as `CELERY`, `CELERYD` or `BROKER`) and a configuration option (such as `HOST` or `ROUTES`); the only exceptions are the `SERVER_EMAIL` and `ADMINS` options. See the `Celery configuration defaults module`_ for a complete listing. Note that many Celery options make no sense in a Zope server context as you would normally only send task messages, not run a worker to process tasks. Using this subdivision, the ZConfig schema for Celery puts these options into a section for each namespace. Thus, all `BROKER` configuration is contained in a `<broker>` section, with each broker option lower-cased, underscores replaced with dashes. An option like `CELERY_TASK_PUBLISH_RETRY` thus becomes `task_publish_retry` in the `<celery>` section. The ZConfig schema enforces the type information set by Celery, and any option that takes a tuple (such as `CELERY_TASK_ERROR_WHITELIST` or `ADMINS`) can be listed multiple times in zope.conf to list all items. Options that take a dictionary (such as `CELERY_RESULT_ENGINE_OPTIONS` or `CELERY_QUEUES`) are configured in zope.conf using a new section with the option name, so in the case of `CELERY_QUEUES` add a `<queues>` section to the `celery` section listing each queue on a new line. Values are interpreted as python expressions. Some options are handled specially: * The `ADMINS` option takes a `name, email address` pair. * `CELERY_TASK_RESULT_EXPIRES` is listed as a time delta using ZConfig formatting. The set of suffixes recognized by ZConfig are: ‘w’ (weeks), ‘d’ (days), ‘h’ (hours), ‘m’ (minutes), ‘s’ (seconds). Values may be floats, for example:4w 2.5d 7h 12m 0.001s. * For the `CELERY_ROUTES` option, you can either specify python classes named by a dotted path or a python dictionary. By using the `%import plone.app.celery` line in your zope.conf configuration file, you automatically configure Celery to use the plone.app.celery loader. If you want to use a different loader, you need to set the `CELERY_LOADER` environment variable before the configuration file is processed.

plone.app.caching-1.1.8-1.lbn13.noarch: Plone UI and default rules for plone.caching/z3c.caching

plone.app.blocks-1.1.1-1.lbn13.noarch: This package implements the 'blocks' rendering model, by providing several transform stages that hook into plone.transformchain. The rendering stages are: plone.app.blocks.parsexml (order 8000) Turns the response in a repoze.xmliter XMLSerializer object. This is then used by the subsequent stages. If the input is not HTML, the transformation is aborted. plone.app.blocks.mergepanels (order 8100) Looks up the site layout and executes the panel merge algorithm. Sets a request variable ('plone.app.blocks.merged') to indicate that it has done its job. plone.app.blocks.tiles (order 8500) Resolve tiles and place them directly into the merged layout. This is the fallback for views that do not opt into ITilePageRendered. plone.app.blocks.esirender (order 8900) Only executed if the request key plone.app.blocks.esi is set and has a true value, as would be the case if any ESI-rendered tiles are included and ESI rendering is enabled globally. This step will serialise the response down to a string and perform some substitution to make ESI rendering work. The package also registers the sitelayout plone.resource resource type, allowing site layouts to be created easily as static HTML files served from resource directories. The URL to a site layout is typically something like: /++sitelayout++my.layout/site.html See plone.resource for more information about how to register resource directories. For site layouts, the type of the resource directory is sitelayout. It is possible to provide a manifest file that gives a title, description and alternative default file for a site layout HTML file in a resource directory. To create such a manifest, put a manifest.cfg file in the layout directory with the following structure: [sitelayout] title = My layout title description = Some description file = some-html-file.html All keys are optional. The file defaults to site.html. A vocabulary factory called plone.availableSiteLayouts is registered to allow lookup of all registered site layouts. The terms in this vocabulary use the URL as a value, the resource directory name as a token, and the title from the manifest (falling back on a sanitised version of the resource directory name) as the title. The current default site layout can be identified by the plone.registry key plone.defaultSiteLayout, which is set to None by default. To always use the current site default, use: <html data-layout="./@@default-site-layout"> The @@default-site-layout view will render the current default site layout. It is possible for the default site layout to be overridden per section, by having parent objects provide or be adaptable to plone.app.blocks.layoutbehavior.ILayoutAware. As the module name implies, this interface can be used as a plone.behavior behavior, but it can also be implemented directly or used as a standard adapter. The ILayoutAware interface defines three properties: content, which contains the body of the page to be rendered pageSiteLayout, which contains the path to the site layout to be used for the given page. It can be None if the default is to be used. sectionSiteLayout, which contains the path to the site layout to be used for pages underneath the given page (but not for the page itself). Again, it can be None if the default is to be used. To make use of the page site layout, use the following: <html data-layout="./@@default-site-layout"> See rendering.txt for detailed examples of how the processing is applied, and esi.txt for details about how Edge Side Includes can be supported.

plone.app.blob-1.5.9-1.lbn13.noarch: This package aims to be an add-on for Plone (>= 3.x) integrating ZODB (>=3.8) blob support, which allows large binary data to be managed by the ZODB, but separately from your usual FileStorage database, i.e. Data.fs. This has several advantages, most importantly a much smaller Data.fs and better performance both cpu- as well as memory-wise.

plone.app.async-1.1-2.lbn13.noarch: You will typically run plone.app.async in a ZEO environment, where you will have one or more worker instances that act as dispatchers carrying out jobs queued by your main zope instances. For the sake of simplicity it is assumed that you have one instance that can queue new jobs, and one worker instance that consumes them, both operating on a single database. * Each instance has to set the ZC_ASYNC_UUID environment variable in order to integrate properly with zc.async. * Each instance loads the single_db_instance.zcml configuration. The worker instance loads the single_db_worker.zcml configuration in order to setup the queue and configure itself as a dispatcher. For more details please look at the example buildout configurations included in the package.

plone.app-1.0.0-1.lbn13.noarch: plone.app module

plone.api-1.1.0-1.lbn13.noarch: The plone.api is an elegant and simple API, built for humans wishing to develop with Plone. It comes with cookbook-like documentation and step-by-step instructions for doing common development tasks in Plone. Recipes try to assume the user does not have extensive knowledge about Plone internals. The intention of this package is to provide clear API methods for Plone functionality which may be confusing or difficult to access. As the underlying code improves some API methods may be deprecated and the documentation here will be updated to show how to use the improved code (even if it means not using plone.api) Some parts of the documentation do not use plone.api methods directly, but simply provide guidance on achieving a task using Plone's internal API. For example, using the portal catalog (see 'Find content objects'). The intention is to cover 20% of the tasks any Plone developer does 80% of the time. By keeping everything in one place, the API stays introspectable and discoverable, important aspects of being Pythonic.

plone.alterego-1.0-2.lbn13.noarch: Now you see it, it now you don't! This package defines a dynamic module type that lets you create objects in the dynamic module on demand. Usage To use this package, you should: * Identify an appropriate parent module where the dynamic module will live. * Ensure that plone.alterego.dynamic.create() is called with this module and a dynamic module name. Typically, you'd do this in the parent module itself, so that the dynamic module is instantiated as soon as the parent module is imported. * Register a named utility providing IDynamicObjectFactory. The name should be the same as the full dotted path to the dynamic module. This utility will be responsible for creating the objects that inhabit the dynamic module.

plone-wc.pageturner-1.2.3-3.lbn13.noarch: This package is a Plone product that will add a Page Turner view to the PDF File content type. The result is that you'll be able to view PDFs much in the same way you can view them on scribd.com. It uses the open source project, Flex Paper, to display the PDFs. You can find information about it at http://flexpaper.devaldi.com/.

plone-4.3.3-1.lbn13.noarch: Plone is ideal as an intranet and extranet server, as a document publishing system, a portal server and as a groupware tool for collaboration between separately located entities. A versatile software product like Plone can be used in a myriad of ways. Look through the sites that use Plone section to see a variety of ways people have implemented Plone and Zope solutions.

perl-Geo-IP-1.40-2.lbn13.x86_64: This package contains Perl bindings for the GeoIP IP/hostname to country/location/organization database. This package requires Maxmind's GeoIP libraries but is often faster than other, similar modules.

perl-Geo-IP-1.40-1.fc18.1302272143kf.armv6hl: This package contains Perl bindings for the GeoIP IP/hostname to country/location/organization database. This package requires Maxmind's GeoIP libraries but is often faster than other, similar modules.

numpy-f2py-1.6.2-6.fc18.armv6hl: This package includes a version of f2py that works properly with NumPy.

numpy-f2py-1.3.0-9.fc13.x86_64: This package includes a version of f2py that works properly with NumPy.

numpy-1.6.2-6.fc18.armv6hl: NumPy is a general-purpose array-processing package designed to efficiently manipulate large multi-dimensional arrays of arbitrary records without sacrificing too much speed for small multi-dimensional arrays. NumPy is built on the Numeric code base and adds features introduced by numarray as well as an extended C-API and the ability to create arrays of arbitrary type. There are also basic facilities for discrete fourier transform, basic linear algebra and random number generation. Also included in this package is a version of f2py that works properly with NumPy.

numpy-1.3.0-9.fc13.x86_64: NumPy is a general-purpose array-processing package designed to efficiently manipulate large multi-dimensional arrays of arbitrary records without sacrificing too much speed for small multi-dimensional arrays. NumPy is built on the Numeric code base and adds features introduced by numarray as well as an extended C-API and the ability to create arrays of arbitrary type. There are also basic facilities for discrete fourier transform, basic linear algebra and random number generation. Also included in this package is a version of f2py that works properly with NumPy.

monit-5.6-4.lbn13.x86_64: Monit is a utility for managing and monitoring, processes, files, directories and devices on a Unix system. Monit conducts automatic maintenance and repair and can execute meaningful causal actions in error situations. E.g. monit can start a process if it does not run, restart a process if it does not respond and stop a process if it uses to much resources. You can use monit to monitor files, directories and devices for changes, such as timestamp changes, checksum changes or size changes. You can even use monit to monitor remote hosts; monit can ping a remote host and check port connections. Authors: -------- Jan-Henrik Haukeland <hauk at tildeslash dot com> Martin Pala <martin.pala at iol dot cz> Rory Toma <rory at digeo dot com> Christian Hopp <chopp at iei dot tu-clausthal dot de>

« Previous 20 items Next 20 items » 1 ... 2372 2373 2374 2375 2376 2377 2378 ... 2425


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

Sections

Modified items