Modified items

All recently modified items, latest first.

zope-zc.buildout-2.1.0-1.lbn13.noarch: Buildout is a project designed to solve 2 problems: 1. Application-centric assembly and deployment Assembly runs the gamut from stitching together libraries to create a running program, to production deployment configuration of applications, and associated systems and tools (e.g. run-control scripts, cron jobs, logs, service registration, etc.). Buildout might be confused with build tools like make or ant, but it is a little higher level and might invoke systems like make or ant to get it's work done. Buildout might be confused with systems like puppet or chef, but it is more application focused. Systems like puppet or chef might use buildout to get their work done. Buildout is also somewhat Python-centric, even though it can be used to assemble and deploy non-python applications. It has some special features for assembling Python programs. It's scripted with Python, unlike, say puppet or chef, which are scripted with Ruby. 2. Repeatable assembly of programs from Python software distributions Buildout puts great effort toward making program assembly a highly repeatable process, whether in a very open-ended development mode, where dependency versions aren't locked down, or in a deployment environment where dependency versions are fully specified. You should be able to check buildout into a VCS and later check it out. Two checkouts built at the same time in the same environment should always give the same result, regardless of their history. Among other things, after a buildout, all dependencies should be at the most recent version consistent with any version specifications expressed in the buildout. Buildout supports applications consisting of multiple programs, with different programs in an application free to use different versions of Python distributions. This is in contrast with a Python installation (real or virtual), where, for any given distribution, there can only be one installed. To learn more about buildout, including how to use it, see http://buildout.org/.

zope-zc.blist-1.0b2-2.lbn13.noarch: The sequence in this package has a list-like API, but stores its values in individual buckets. This means that, for small changes in large sequences, the sequence could be a big win. For instance, an ordered BTree-based container might want to store order in a sequence, so that moves only cause a bucket or two--around 50 strings or less--to be rewritten in the database, rather than the entire contents (which might be thousands of strings, for instance). If the sequence is most often completely rearranged, the complexity of the code in this package is not desirable. It only makes sense if changes most frequently are fairly small. One downside is that reading and writing is more work than with a normal list. If this were to actually gain traction, perhaps writing some or all of it in C would be helpful. However, it still seems pretty snappy. Another downside is the corollary of the bucket advantage listed initially: with more persistent objects, iterating over it will fill a lot of ZODB's object cache (which is based on the number of objects cached, rather than the size). Consider specifying a big object cache if you are using these to store a lot of data and are frequently iterating or changing. These sequences return slices as iterators, and add some helpful iteration methods. It adds a copy method that provides a cheap copy of the blist that shares all buckets and indexes until a write happens, at which point it copies and mutates the affected indexes and buckets. We'll take a glance at how these differences work, and then describe the implementation's basic mechanism, and close with a brief discussion of performance characteristics in the abstract.

zope-zc.async-1.5.4-4.lbn13.noarch: The zc.async package provides an easy-to-use Python tool that schedules work persistently and reliably across multiple processes and machines. For instance... * Web apps: maybe your web application lets users request the creation of a large PDF, or some other expensive task. * Postponed work: maybe you have a job that needs to be done at a certain time, not right now. * Parallel processing: maybe you have a long-running problem that can be made to complete faster by splitting it up into discrete parts, each performed in parallel, across multiple machines. * Serial processing: maybe you want to decompose and serialize a job. High-level features include the following: * easy to use; * flexible configuration, changeable dynamically in production; * reliable; * supports high availability; * good debugging tools; * well-tested; and * friendly to testing. While developed as part of the Zope project, zc.async can be used stand-alone. How does it work? The system uses the Zope Object Database (ZODB), a transactional, pickle-based Python object database, for communication and coordination among participating processes. zc.async participants can each run in their own process, or share a process (run in threads) with other code. The Twisted framework supplies some code (failures and reactor implementations, primarily) and some concepts to the package.

zope-zc-1.1-1.lbn13.noarch: Zope Corp base module hierarchy

zope-zLOG-2.11.1-2.lbn13.noarch: A general logging facility

zope-zExceptions-2.13.0-2.lbn13.noarch: zExceptions contains common exceptions used in Zope2.

zope-z3c.zcmlhook-1.0b1-2.lbn13.noarch: z3c.zcmlhook

zope-z3c.widgets.flashupload-1.0c1-4.lbn13.noarch

zope-z3c.widgets-1.0c1-4.lbn13.noarch: Zope 3 widget base module hierarchy

zope-z3c.template-1.4.1-2.lbn13.noarch: This package allows you to register templates independently from view code. In Zope 3, when registering a browser:page both presentation and computation are registered together. Unfortunately the registration tangles presentation and computation so tightly that it is not possible to re-register a different template depending on context. (You can override the whole registration but this is not the main point of this package.) With z3c.template the registration is split up between the view and the template and allows to differentiate the template based on the skin layer and the view. In addition this package lays the foundation to differentiate between templates that provide specific presentation templates and generic layout templates.

zope-z3c.tabular-0.6.2-1.lbn13.noarch: This package provides a table implementation including form support for Zope3 based on z3c.form and z3c.table.

zope-z3c.table-2.0.0a1-1.lbn13.noarch: The goal of this package is to offer a modular table rendering library. We use the content provider pattern and the column are implemented as adapters which will give us a powerful base concept. Some important concepts we use * separate implementation in update render parts, This allows to manipulate data after update call and before we render them. * allow to use page templates if needed. By default all is done in python. * allow to use the rendered batch outside the existing table HTML part. No skins This package does not provide any kind of template or skin support. Most the time if you need to render a table, you will use your own skin concept. This means you can render the table or batch within your own templates. This will ensure that we have as few dependencies as possible in this package and the package can get reused with any skin concept. Note As you probably know, batching is only possible after sorting columns. This is a nightmare if it comes to performance. The reason is, all data need to get sorted before the batch can start at the given position. And sorting can most of the time only be done by touching each object. This means you have to be careful if you are using a large set of data, even if you use batching.

zope-z3c.sqlalchemy-1.4.0-2.lbn13.noarch: What is z3c.sqlalchemy? z3c.sqlalchemy is yet another wrapper around SQLAlchemy. The functionality of the wrapper is basically focused on easy integration with Zope 2 and Zope 3. The wrapper cares about connection handling, optional transaction integration with Zope 2/3 and wrapper management (caching, introspection). z3c.sqlalchemy gives you flexible control over the mapper creation. Mapper classes can be * auto-generated (with or without autodetection of table relationships) * configured by the developer What z3c.sqlalchemy does not do and won't do: * no support for Zope 3 schemas * no support for Archetypes schemas z3c.sqlachemy just tries to provide you with the basic functionalities you need to write SQLAlchemy-based applications with Zope 2/3. Higher-level functionalities like integration with Archetypes/Zope 3 schemas are subject to higher-level frameworks. z3c.sqlalchemy does not address these frameworks.

zope-z3c.relationfield-0.6.2-3.lbn13.noarch: A relation field framework for Zope 3.

zope-z3c.recipe.sphinxdoc-0.0.8-3.lbn13.noarch: Use Sphinx to build documentation for zope.org.

zope-z3c.recipe.scripts-1.0.1-2.lbn13.noarch: Recipe for installing Python scripts

zope-z3c.recipe.depgraph-0.5-2.lbn13.noarch: Buildout recipe to generate dependency graphs.

zope-z3c.recipe.compattest-0.12.2-2.lbn13.noarch: Buildout recipe to create testrunners for testing compatibility with other packages

zope-z3c.ptcompat-1.0.1-2.lbn13.noarch: This package provides a page template engine implementation based on Chameleon. It plugs into the zope.pagetemplate package and has an explicit dependency on this package. You can use the package to replace Zope's reference template engine with Chameleon in an application based on the Zope Toolkit.

zope-z3c.pt-2.2.3-3.lbn13.noarch: This is a fast implementation of the ZPT template engine for Zope 3 which uses Chameleon to compile templates to byte-code. The package provides application support equivalent to zope.app.pagetemplate.

« Previous 20 items Next 20 items » 1 ... 2341 2342 2343 2344 2345 2346 2347 ... 2421


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

Sections

Modified items