Modified items

All recently modified items, latest first.

plone.testing-5.1-1.lbn25.noarch: plone.testing provides tools for writing unit and integration tests in a Zope and Plone environment. It is not tied to Plone, and it does not depend on Zope 2 (although it has some optional Zope 2-only features). plone.testing builds on zope.testing, in particular its layers concept. This package also aims to promote some “good practice” for writing tests of various types. Note If you are working with Plone, there is a complementary package plone.app.testing, which builds on plone.testing to provide additional layers useful for testing Plone add-ons.

plone.synchronize-1.0.4-1.lbn19.noarch: This package provides a simple decorator to help synchronize methods across threads, to avoid problems of concurrent access.

plone.supermodel-1.3.0-1.lbn25.noarch: plone.supermodel provides XML import and export for schema interfaces based on zope.schema fields. The principal use cases are: 1. Define a schema interface in code based on an XML file. This can be done with syntax like: >>> from plone.supermodel import xmlSchema >>> IMySchema = xmlSchema("myschema.xml") 2. Save and load interface definitions via an XML format. To turn a schema interface into XML, you can do: >>> from plone.supermodel import serializeSchema >>> xml_string = serializeSchema(IMySchema) To get a schema from an XML file, you can use the xmlSchema() function above, or you can use the more powerful spec() function, which turns a dict of all schemata and widget hints in a given XML file. See schema.txt and interfaces.py in the source code for more information, including details on how to give widget hints for forms and how to keep multiple schemata in the same XML file. Supermodel vs. Userschema This package is quite similar to Tres Seaver's "userschema" library, which can be found at http://agendaless.com/Members/tseaver/software/userschema. In fact, plone.supermodel was originally based on userschema. However, as the package was refined and refactored, less and less of userschema remained, to the point where we'd have needed to significantly refactor the latter to keep using it. The XML import/export code is currently based on algorithms that were written for plone.app.portlets and plone.app.contentrules' GenericSetup handlers. Some of the key differences between the two packages are: userschema can create schema interfaces from HTML forms and CSV spreadsheets. plone.supermodel does not support such configuration. Schemata created with userschema are typically loaded at startup, with a ZCML directive. plone.supermodel supports a "pseudo-base class" syntax, as seen above, to define interfaces in Python code. Beyond that, its API is more geared towards runtime configuration. plone.supermodel supports serialisation of schemata to XML. The plone.supermodel XML syntax is more directly tied to zope.schema fields, and infers most parameters from the schema interface declared by each zope.schema field. This has two advantages: API documentation for zope.schema can be easily applied to <schema /> blocks New fields and obscure attributes are easier to support plone.supermodel's XML schema is intended to support more schema metadata, including widget hints.

plone.subrequest-1.8.7-1.lbn19.noarch: plone.subrequest provides a mechanism for issuing subrequests under Zope2.

plone.stringinterp-1.2.1-1.lbn25.noarch: Provides ${id} style string interpolation using named adapters to look up variables. This is meant to provide a trivially simple template system for clients like plone.app.contentrules. To interpolate a string in context, just follow the pattern: from plone.stringinterp.interfaces import IStringInterpolator IStringInterpolator(context)("Here is the title: ${title}") Substitution of variables that are part of the Dublin Core are provided with the package. To provide additional substitutions, just provide a named adapter implementing interfaces.IStringSubstitution for your context. The adapter name is used for the lookup. You can also wrap your context with IContextWrapper adapter if you need to pass custom messages within your substitutions.

plone.session-3.6.2-1.lbn25.noarch: plone.session implements secure session management for Zope sites. It can be used directly, or be used as a base for custom session management strategies. In its default configuration plone.sessions uses a secure cryptographic hash based on HMAC_ SHA-1_ to authenticate sessions. The hash is generated using the users login name and a secret stored in the PAS plugin. This has several advantages over other session management systems: * passwords are not send to the server in a cookie on every request, as is done by the *Cookie Auth Helper* * it does not require any ZODB write for sessions, as is needed by the *Session Crumbler*. This allows it to scale very well. * it allows you to invalidate all existing authentication cookies for users by updating the secret. Normally a session cookie is used to track sessions; that means that as long as a user keeps his browser open (and does not explicitly log out) the session remains opens. This can be changed by setting the ``cookie_lifetime`` property of the plugin to the number of seconds the cookie should remain valid *after the moment of login*. Using plone.session ------------------- plone.session only takes care of handling sessions for already authenticated users. This means it can not be used stand-alone: you need to have another PAS plugin, such as the standard *Cookie Auth Helper* to take care of authentication. After a user has been authenticated plone.session can take over via the PAS *credentials update* mechanism. Using custom session authentication ----------------------------------- plone.session delegates the generation and verification of sessions to an ISessionSource adapter. This adapter adapts the PAS plugin and implements four methods: createIdentifier Return an identifier for a userid. An identifier is a standard python string object. verifyIdentifier Verify if an identity corresponds to a valid session. Returns a boolean indicating if the identify is valid. extractLoginName Extract the login name from an identifier. invalidateSession Mark a session for a principal as invalid. A source may not support this, in which case it should return False. plone.session ships with two example adapers: hash and userid. The userid adapter is a trivial example which uses the userid as session identifier. This is very insecure since there is no form of verification at all. DO NOT USE THIS ADAPTER IN YOUR SITE! The hash plugin creates a random secret string which is stored as an attribute on your plugin. It uses this secret to create a SHA1 signature for the user id with the secret as session identifier. This approach has several good qualities: * it allows us to verify that a session identifier was created by this site * there is no need to include passwords in the session idenfitier * it does not need to store anything in Zope itself. This means it works as-is in ZEO setups and can scale very well. There are a few downsides to this approach: * if a users password is changed or disabled session identifiers will continue to work, making it hard to lock out users

plone.schemaeditor-2.0.9-1.lbn25.noarch: plone.schemaeditor provides a through-the-web interface for modifying Zope 3 schemata (interfaces). Currently there is support for: * adding and removing fields * editing attributes of existing fields * reordering fields * renaming fields plone.schemaeditor only handles the actual schema editing. To be useful, it requires some integration code to take care of the following pieces: * traversing to a schema that is used as the context of the editor * persisting schema changes across Zope restarts See plone.app.dexterity (along with plone.dexterity and plone.supermodel) for one approach to this integration. The following field types (from zope.schema) are currently supported: * TextLine * Text * Int * Float * Bool * Password * Datetime * Choice (with simple list of values) * List of Choice (with simple list of values) Third-party packages can make additional field types available by registering new IFieldFactory utilities.

plone.schema-1.2.0-1.lbn25.noarch: Plone specific extensions and fields for zope schematas.

plone.scale-2.1-2.lbn25.noarch: This package contains image scaling logic for use in Zope environments. It supports Zope 2, grok and other systems build on using the Zope ToolKit (ZTK). Several design goals were used when writing this package: image scaling to any width, height, width&height should be supported using both up-scaling and down-scaling. Scaling parameters should never be fixed in code. This allows designers to use any image scale they want without having to modify python code. the result of scaling will be an image along with its new size, not a HTML or XHTML tag. We already have excellent tools to generate tags in the form of Zope Pagetemplates, Genshi and other template languages that are much better suited for this purpose. In addition several implementation goals were defined: image scaling must happen on demand instead of up-front. This reduces initial save time and prevents unnecessary scalings from being generated. image scaling parameters should not be part of the generated URL. Since the number of parameters can change and new parameters may be added in the future this would create overly complex URLs and URL parsing. no HTML rewriting (such as done by repoze.bitblt) should be required. it should be possibly to develop an external storage system which stores scaled images externally and returns a URL which bypasses the application server. This should be configurable via just a filesystem path & base URL. minimum number of external dependencies, allowing this package to be used in many environments. testable without requiring zope.testing. Running setup.py test should be sufficient. URLs for scaled images should have an extension which reflects their MIME type. This is facilitates cache (and other front-end services) configuration.

plone.rfc822-1.1.4-1.lbn25.noarch: This package provides primitives for turning content objects described by zope.schema fields into RFC (2)822 style messages, as managed by the Python standard library's email module. It consists of: * A marker interface IPrimaryField which can be used to indicate the primary field of a schema. The primary field will be used as the message body. * An interface IFieldMarshaler which describes marshalers that convert to and from strings suitable for encoding into an RFC 2822 style message. These are adapters on (context, field), where context is the content object and field is the schema field instance. * Default implementations of IFieldMarshaler for the standard fields in the zope.schema package. * Helper methods to construct messages from one or more schemata or a list of fields, and to parse a message and update a context object accordingly.

plone.restapi-4.3.1-1.lbn25.noarch: REST stands for `Representational State Transfer`_. It is a software architectural principle to create loosely coupled web APIs. Most web APIs have a tight coupling between client and server. This makes them brittle and hard to change over time. It requires them not only to fully document every small detail of the API, but also write a client implementation that follows that specification 100% and breaks as soon as you change any detail. A hypermedia API just provides an entry point to the API that contains hyperlinks the clients can follow. Just like a human user of a regular website, that knows the initial URL of a website and then follows hyperlinks to navigate through the site. This has the advantage that the client just needs to understand how to detect and follow links. The URL and other details of the API can change without breaking the client.

plone.resourceeditor-1.0.1-1.lbn25.noarch: This package contains resources for integrating ACE (http://ace.ajax.org/) into Plone, with a file manager that can edit plone.resource resource directories in the ZODB. ACE can be found under ++resource++plone.resourceeditor/ace/*. The file manager can be included in a view with the following in the header: <metal:block use-macro="resourceDirectory/@@plone.resourceeditor.filemanager/macros/resources" /> and the following in the body: <metal:block use-macro="resourceDirectory/@@plone.resourceeditor.filemanager/macros/filemanager"> In both of these cases, resourceDirectory should be an in-ZODB plone.resource resource directory instance.

plone.resource-1.2.3-1.lbn25.noarch: plone.resource publishes directories of static files via the ZPublisher. These directories may be located either in the ZODB (as OFS folders and files), or on the filesystem. Each resource directory has a type and a name. When combined, these are used to traverse to the resource directory. For example: /++theme++mytheme/<subpath> /++sitelayout++mylayout/<subpath> /++templatelayout++mylayout<subpath>

plone.reload-3.0.1-1.lbn19.noarch: While being logged into the ZMI as an user with the Manager role visit /@@reload on your Zope application root via a browser. If your Zope is configured to listen on port 8080 on localhost this is: http://localhost:8080/@@reload If you get a Resource not found error, make sure you have loaded the configure.zcml file from this library and you really use the ZODB application root and not a Plone site as the base url. When you press the Reload Code button, all modules that have been changed since the last time they were loaded are reloaded. You'll get a status message telling you which modules have been reloaded. To reload all ZCML without a restart, press the 'Reload Code and ZCML' button. The action to perform is determined via a simple query string, so once you did a 'Reload Code' once, you can simply reload the browser page to execute the action once again. Caveats: There's some code structures which cannot be reloaded via the approach underlying this library. Plone portlets and content types are two examples of this. In general decorators will currently not always work.

plone.relations-2.0-1.lbn19.noarch: Tools for defining and querying complex relationships between objects. This product builds on and requires zc.relationship and also five.intid.

plone.registry-1.1.2-1.lbn25.noarch: This package provides debconf-like (or about:config-like) settings registries for Zope applications. A ``registry``, with a dict-like API, is used to get and set values stored in ``records``. Each record contains the actual value, as well as a ``field`` that describes the record in more detail. At a minimum, the field contains information about the type of value allowed, as well as a short title describing the record's purpose. See the following doctests for more details: * ``registry.rst``, which demonstrates how registries and records work * ``events.rst``, which shows the events that are fired from the registry * ``field.rst``, which describes the behaviour of persistent fields

plone.recipe.zope2zeoserver-1.4-3.lbn19.noarch: This recipe creates and configures a Zope 2 ZEO server in parts. It also installs a control script, which is like zeoctl, in the bin/ directory. The name of the control script is the the name of the part in buildout. You can use it with a part like this:: [zeoserver] recipe = plone.recipe.zope2zeoserver zope2-location = /path/to/zope2/install zeo-address = 8100 Options ------- zope2-location The path where Zope 2 is installed. If you are also using the plone.recipe.zope2install recipe, and you have that configured as a part called 'zope2' prior to the zope2zeoserver part, you can use ${zope2:location} for this parameter. You must ensure the zope2zeoserver part is run *after* the zope2install one. zeopack The path to the zeopack.py backup script. A wrapper for this will be generated in bin/zeopack, which sets up the appropriate environment to run this. Defaults to "${zope2-location}/utilities/ZODBTools/zeopack.py". Set this option to an empty value if you do not want this script to be generated. repozo The path to the repozo.py backup script. A wrapper for this will be generated in bin/repozo, which sets up the appropriate environment for running this. Defaults to "${zope2-location}/utilities/ZODBTools/repozo.py". Set this to an empty value if you do not want this script to be generated. zeo-conf A relative or absolute path to a zeo.conf file. If this is not given, a zeo.conf will be generated based on the the options below. The following options all affect the generated zope.conf. zeo-address Give a port for the ZEO server (either specify the port number only (with 'localhost' as default) or you use the format ``host:port``). Defaults to 8100. effective-user The name of the effective user for the ZEO process. Defaults to not setting an effective user. invalidation-queue-size The invalidation-queue-size used for the ZEO server. Defaults to 100. zeo-log The filename of the ZEO log file. Defaults to var/log/${partname}.log zeo-log-format Format of logfile entries. Defaults to %(asctime)s %(message)s zeo-log-custom A custom section for the eventlog, to be able to use another event logger than `logfile`. `zeo-log` is still used to set the logfile value in the runner section. storage-number The number used to identify a storage. file-storage The filename where the ZODB data file will be stored. Defaults to var/filestorage/Data.fs. blob-storage The folder where the ZODB blob data files will be stored. socket-name The filename where ZEO will write its socket file. Defaults to var/zeo.zdsock. authentication-database The filename for a authentication database. Only accounts listed in this database will be allowed to access the ZEO server. The format of the database file is:: realm <realm> <username>:<hash> Where the hash is generated via:: import sha string = "%s:%s:%s" % (username, realm, password) sha.new(string).hexdigest() authentication-realm The authentication realm. Defaults to 'ZEO' pack-days Specify of days for the zeopack script to retain of history. Defaults to one day. pack-user If the ZEO server uses authentication, this is the username used by the zeopack script to connect to the ZEO server. pack-password If the ZEO server uses authentication, this is the password used by the zeopack script to connect to the ZEO server. zeo-conf-additional Give additional lines to zeo.conf. Make sure you indent any lines after the one with the parameter. monitor-address The address at which the monitor server should listen. The monitor server provides server statistics in a simple text format. relative-paths Set this to `true` to make the generated scripts use relative paths. You can also enable this in the `[buildout]` section.

plone.recipe.zope2instance-4.4.1-1.lbn25.noarch: This recipe creates and configures a Zope 2 instance in parts. It also installs a control script, which is like zopectl, in the bin/ directory. The name of the control script is the the name of the part in buildout. You can use it with a part like this:: [instance] recipe = plone.recipe.zope2instance zope2-location = /path/to/zope2/install user = admin:admin http-address = 8080 eggs = ${buildout:eggs} my.package products = ${buildout:directory}/products zcml = my.package Options ------- zope2-location The path where Zope 2 is installed. If you are also using the plone.recipe.zope2install recipe, and you have that configured as a part called 'zope2' prior to the zope2instance part, you can use ${zope2:location} for this parameter. zope-conf A relative or absolute path to a zope.conf file. If this is not given, a zope.conf will be generated based on the the options below. repozo The path to the repozo.py backup script. A wrapper for this will be generated in bin/repozo, which sets up the appropriate environment for running this. Defaults to "${zope2-location}/utilities/ZODBTools/repozo.py". Set this to an empty value if you do not want this script to be generated. The following options all affect the generated zope.conf: products A list of paths where Zope 2 products are installed. The first path takes precedence in case the same product is found in more than one directory. site-zcml If you want a custom site.zcml file, put its content here. If this option is used the zcml and zcml-additional options are ignored. zcml Install ZCML slugs for the packages listed, separated by whitespace. You can specify the type of slug by appending '-' and the type of slug you want to create. The valid types are configure, overrides and meta. Some examples: my.package-overrides my.package-meta zcml-additional Extra ZCML statements that should be included in the generated site.zcml file. extra-paths A list of paths where additional python packages are installed. The paths are searched in the given order after all egg and products paths. default-zpublisher-encoding This controls what character set is used to encode unicode data that reaches ZPublisher without any other specified encoding. This defaults to 'utf-8'. debug-mode Set to 'on' to turn on debug mode in Zope. Defaults to 'off'. verbose-security Set to 'on' to turn on verbose security (and switch to the Python security implementation). Defaults to 'off' (and the C security implementation). effective-user The name of the effective user for the Zope process. Defaults to not setting an effective user. ip-address The default IP address on which Zope's various server protocol implementations will listen for requests. If this is unset, Zope will listen on all IP addresses supported by the machine. This directive can be overridden on a per-server basis in the servers section. Defaults to not setting an ip-address. port-base Offset applied to the port numbers used for ZServer configurations. For example, if the http-server port is 8080 and the port-base is 1000, the HTTP server will listen on port 9080. This makes it easy to change the complete set of ports used by a Zope server process. Zope defaults to 0. http-address Give a port for the HTTP server. Defaults to 8080. http-fast-listen Set to off to defer opening of the HTTP socket until the end of the Zope startup phase. Defaults to on. Note: This option requires Zope >= 2.11. ftp-address Give a port for the FTP server. This enables the FTP server. webdav-address Give a port for the WebDAV server. This enables the WebDAV server webdav-force-connection-close Valid options are off and on. Defaults to off client-home Sets the clienthome for the generated instance. Defaults to ${buildout:directory}/var/<name of the section>. var Used to configure the base directory for all things going into var. Defaults to ${buildout:directory}/var. event-log The filename of the event log. Defaults to var/log/${partname}.log event-log-custom A custom section for the eventlog, to be able to use another event logger than 'logfile' event-log-level Set the level of the console output for the event log. Level may be any of CRITICAL, ERROR, WARN, INFO, DEBUG, or ALL. Defaults to INFO. z2-log The filename for the Z2 access log. Defaults to var/log/${partname}-Z2.log. z2-log-level Set the log level for the access log. Level may be any of CRITICAL, ERROR, WARN, INFO, DEBUG, or ALL. Defaults to WARN. access-log-custom Like 'event-log-custom', a custom section for the access logger, to be able to use another event logger than `logfile`. file-storage The filename where the ZODB data file will be stored. Defaults to var/filestorage/Data.fs. demo-storage If 'on' it enables the demostorage. It is not compatible with blob-storage and rel-storage. blob-storage The name of the directory where the ZODB blob data will be stored. rel-storage Allows to set a RelStorage instead of a FileStorage. Contains settings separated by newlines, with these values: - type: any database type supported (postgresql, oracle, mysql) - all other keys are passed on to the database-specific RelStorage adapter. Example:: rel-storage = type oracle dsn (DESCRIPTION=(ADDRESS=(HOST=s01))(CONNECT_DATA=(SERVICE_NAME=d01))) user tarek password secret zeo-client Set to 'on' to make this instance a ZEO client. In this case, setting the zeo-address option is required, and the file-storage option has no effect. To set up a ZEO server, you can use the plone.recipe.zope2zeoserver recipe. Defaults to 'off'. shared-blob If 'zeo-client' is set to 'on' and 'blob-storage' is set to a directory that is shared between this instance and the ZEO server (as configured by the 'blob-dir' setting on zeo.conf, then setting 'shared-blob' to 'on' causes this instance not to stream the blob file through the ZEO connection, but just to send the information of the file location to the ZEO server. zeo-address Set the address of the ZEO server. Defaults to 8100. zeo-client-name Set the name of the ZEO client. Defaults to the name of the part. If a false value is provided no zeo-client-name will be set. zeo-client-cache-size Set the size of the ZEO client cache. Defaults to '30MB'. zeo-client-client Set the persistent cache name that is used to construct the cache filenames. Persistent cache files are disabled by default. zeo-storage Set the storage number of the ZEO storage. Defaults to '1'. zeo-var Used in the zeo storage snippets to configure the zeo var folder. Defaults to $INSTANCE_HOME/var. zeo-username Enable ZEO authentication and use the given username when accessing the ZEO server. It is obligatory to also specify a zeo-password. zeo-password Password to use when connecting to a ZEO server with authentication enabled. zeo-realm Authentication realm to use when authentication with a ZEO server. Defaults to 'ZEO'. zodb-cache-size Set the ZODB cache size, i.e. the number of objects which the ZODB cache will try to hold. Defaults to 5000. zodb-cache-size-bytes Set the ZODB cache sizes in bytes. Requires ZODB 3.9 or later. zserver-threads Specify the number of threads that Zope's ZServer web server will use to service requests. You shouldn't change this unless you know what you are doing. Zope's default is 4. zodb-temporary-storage If given Zope's default temporary storage definition will be replaced by the lines of this parameter. environment-vars Define arbitrary key-value pairs for use as environment variables during Zope's run cycle. Example:: environment-vars = TZ US/Eastern TMP /var/tmp DISABLE_PTS True zope-conf-additional Give additional lines to zope.conf. Make sure you indent any lines after the one with the parameter. Example:: zope-conf-additional = locale fr_FR http-realm Slipknot

plone.recipe.zope2install-3.2-5.lbn25.noarch: Options ------- To specify which Zope 2 to use, use one of the following options: url The URL to a tarball to use for the Zope 2 installation. svn The URL for an subversion checkout to use for the Zope 2 installation. location The path to a local, existing Zope 2 installation. Note: For this to work Zope must have been built with the same Python used to run buildout. fake-zope-eggs If set to true, add fake egg links to Zope 3 libraries, so that setuptools can see and use them for dependencies lookup. Enabled by default since version 3.0 of this recipe. additional-fake-eggs Specify an optional list of additional fake eggs. Only include packages which are available on the Python path. You can also specify an explicit version to fake for an egg. For example:: additional-fake-eggs = ZODB3 = 3.7.1 zope.annotation = 3.3.2 Otherwise the faked eggs will always have version 0.0. The default value includes Acquisition, ClientForm, DateTime, docutils, ExtensionClass, mechanize, Persistence, pytz, RestrictedPython, tempstorage, ZConfig, zLOG, zodbcode, ZODB3, zdaemon and Zope2. skip-fake-eggs Specify an optional list of packages, for whom no fake egg is created. This allows to pull in new versions of some of the Zope packages via normal version requirements. smart-recompile Will not recompile Zope if it finds .so or .pyd files. This means you can move your buildout around and speed up builds. If you use many buildouts with the same Zope 2 version, then you can add "zope-directory" in the "buildout" section in your ~/.buildout/default.cfg file like this:: [buildout] zope-directory = /home/me/buildout/zope For installations from a tarball that directory will be used instead of the parts directory in your buildout. Each version of Zope will get it's own directory but if it's already installed the existing one will be reused. Exported variables ------------------ The following variables are set by this recipe and can be used in other parts. location The path to the Zope installation root. Reporting bugs or asking questions ---------------------------------- We have a shared bug tracker and help desk on Launchpad: https://bugs.launchpad.net/collective.buildout/

plone.recipe.zeoserver-1.3.1-1.lbn25.noarch: ZC Buildout recipe for installing a ZEO server

« Previous 20 items Next 20 items » 1 ... 573 574 575 576 577 578 579 ... 2449


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

Sections

Modified items