Modified items

All recently modified items, latest first.

python-diazo-1.2.5-1.lbn25.noarch: Diazo implements a Deliverance like language using a pure XSLT engine. With Diazo, you "compile" your theme and ruleset in one step, then use a superfast/simple transform on each request thereafter. Alternatively, compile your theme during development, check it into Subversion, and not touch Diazo during deployment. Diazo allows you to apply a theme contained in a static HTML web page to a dynamic website created using any server-side technology. With Diazo, you can take an HTML wireframe created by a web designer and turn it into a theme for your favourite CMS, redesign the user interface of a legacy web application without even having access to the original source code, or build a unified user experience across multiple disparate systems, all in a matter of hours, not weeks. When using Diazo, you will work with syntax and concepts familiar from working with HTML and CSS. And by allowing you seamlessly integrate XSLT into your rule files, Diazo makes common cases simple and complex requirements possible. For detailed documentation, please see diazo.org.

python-diazo-1.2.5-1.lbn25.noarch: Diazo implements a Deliverance like language using a pure XSLT engine. With Diazo, you "compile" your theme and ruleset in one step, then use a superfast/simple transform on each request thereafter. Alternatively, compile your theme during development, check it into Subversion, and not touch Diazo during deployment. Diazo allows you to apply a theme contained in a static HTML web page to a dynamic website created using any server-side technology. With Diazo, you can take an HTML wireframe created by a web designer and turn it into a theme for your favourite CMS, redesign the user interface of a legacy web application without even having access to the original source code, or build a unified user experience across multiple disparate systems, all in a matter of hours, not weeks. When using Diazo, you will work with syntax and concepts familiar from working with HTML and CSS. And by allowing you seamlessly integrate XSLT into your rule files, Diazo makes common cases simple and complex requirements possible. For detailed documentation, please see diazo.org.

python-beautifulsoup4-4.5.1-1.fc25.noarch: Beautiful Soup is a Python HTML/XML parser designed for quick turnaround projects like screen-scraping. Three features make it powerful: Beautiful Soup won't choke if you give it bad markup. Beautiful Soup provides a few simple methods and Pythonic idioms for navigating, searching, and modifying a parse tree. Beautiful Soup automatically converts incoming documents to Unicode and outgoing documents to UTF-8. Beautiful Soup parses anything you give it. Valuable data that was once locked up in poorly-designed websites is now within your reach. Projects that would have taken hours take only minutes with Beautiful Soup.

python-BastionBanking-5.0.0-1.lbn25.noarch: Pure python modules for currency and credit card management

plone.z3cform-0.9.1-1.lbn25.noarch: plone.z3cform is a library that allows use of z3c.form with Zope 2 and the CMF.

plone.uuid-1.0.6-1.lbn25.noarch: UUIDs for content items

plone.transformchain-1.2.2-1.lbn25.noarch: Hook into repoze.zope2 that allows third party packages to register a sequence of hooks that will be allowed to modify the response before it is returned to the browser

plone.tiles-1.8.1-1.lbn25.noarch: For the purposes of this package, a tile is a browser view and an associated utility providing some metadata about that view. The metadata includes a title and description, an 'add' permission and optionally a schema interface describing configurable aspects of the tile. The idea is that a UI (such as Deco) can present the user with a list of insertable tiles and optionally render a form to configure the tile upon insertion. A tile is inserted into a layout as a link: <link rel="tile" target="placeholder" href="./@@sample.tile/tile1?option1=value1" /> The sub-path (tile1` in this case) is used to set the tile id attribute. This allows the tile to know its unique id, and, in the case of persistent tiles, look up its data. sample.tile is the name of the browser view that implements the tile. This is made available as the __name__ attribute. Other parameters may be turned into tile data, available under the data attribute, a dict, for regular tiles. For persistent tiles (those deriving from the PersistentTile base class), the data is fetched from annotations instead, based on the tile id. There are three interfaces describing tiles in this package: * IBasicTile is the low-level interface for tiles. It extends IBrowserView to describe the semantics of the __name__ and id attributes. * ITile describes a tile that can be configured with some data. The data is accessible via a dict called data. The default implementation of this interface, plone.tiles.Tile, will use the schema of the tile type and the query string (self.request.form) to construct that dictionary. This interface also describes an attribute url, which gives the canonical tile URL, including the id sub-path and any query string parameters. (Note that tiles also correctly implement IAbsoluteURL.) * IPersistentTile describes a tile that stores its configuration in object annotations, and is needed when configuration values cannot be encoded into a query string. The default implementation is in plone.tiles.PersistentTile. To make it possible to have several tiles of a given type on the same layout, the annotations are keyed by the tile __name__. In addition, tiles are described by ITileType, which contains attributes for the tile name, title, description, add permission and schema (if required). A properly configured tile, then, consists of a browser view providing IBasicTile or one of its derivatives, and a utility providing ITileType with the same name as the tile browser view. There is a convenience ZCML directive - <plone:tile /> - to register both of these components in one go. To support creation of appropriate tile links, plone.tiles.data contains two methods - encode() and decode() - to help turn a data dictionary into a query string and turn a request.form dict into a data dict that complies with a tile's schema interface.

plone.theme-2.1.5-1.lbn25.noarch: This package lets you mark the request with a "layer" interface conditional on the currently selected skin (theme) in the portal_skins tool. Most Zope 3 "visual" directives, like <browser:page /> or <browser:viewlet /> accept a 'layer' attribute, which should point to an interface. Recall that a view is a multi-adapter on (context, request). Most views are registered so that the 'request' being adapted only needs to provide Interface. This is equivalent to saying layer="*". By applying a marker interface to the request, and registering a view or viewlet with this interface as the adapted 'layer', we can override a more general view, or make a viewlet that is only shown for a particular layer. In the context of CMF and Plone, we'd like to tie the layer to the current skin selection. We do that by name. What you have to do First, you should create a marker interface: >>> from zope.interface import Interface >>> class IMyTheme(Interface): ... """Marker interface for skins part of 'My Theme' ... """ Then, register this as a theme layer in ZCML: <interface interface=".interfaces.IMyTheme" type="zope.publisher.interfaces.browser.IBrowserSkinType" name="My Theme" /> The title here must match the name of the theme/skin selection in portal_skins. How it works Behind the scenes, the <interface /> registration marks IMyTheme with the "IInterface" IThemelayer, and registers IMyTheme as a utility named "My Theme" and providing IBrowserSkinType. We do something to this effect in tests/tests.zcml. Let us define the "My Theme" skin selection: >>> from Products.CMFCore.utils import getToolByName >>> portal_skins = getToolByName(self.portal, 'portal_skins') >>> default_skin = portal_skins.getDefaultSkin() >>> skin_path = portal_skins._getSelections()[default_skin] >>> portal_skins.addSkinSelection('My Theme', skin_path) In tests/tests.zcml we have registered two version of a view called @@layer-test-view. One, for the default skin layer, simply outputs "Default". The other outputs "My Theme". Before we turn on the skin, we will get the default view. >>> from Products.Five.testbrowser import Browser >>> browser = Browser() >>> browser.open(self.portal.absolute_url() + '/@@layer-test-view') >>> print browser.contents Default However, if we turn the skin on, we should see the effects of the marker interface being applied. >>> portal_skins.default_skin = 'My Theme' >>> browser.open(self.portal.absolute_url() + '/@@layer-test-view') >>> print browser.contents My Theme And if we switch back: >>> portal_skins.default_skin = 'Plone Default' >>> browser.open(self.portal.absolute_url() + '/@@layer-test-view') >>> print browser.contents Default

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.lbn25.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.lbn25.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.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.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>

« Previous 20 items Next 20 items » 1 ... 645 646 647 648 649 650 651 ... 2449


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

Sections

Modified items