Software

New membrane and remember Maintainer - Rob Miller announced today that I'll be the new maintainer

ross — 2008-12-03T02:00:54Z

In a post to the remember list today, Rob Miller announced what we've been discussing for a while, I'm now the new maintainer for membrane and remember. I was stoked when he asked and since then we've had some great discussions so I'm even more stoked now. :)

I've subsequently posted a survey in hopes of getting a sense of what people are using membrane and remember for and what direction they'd like to see them take. It should only take a few seconds to respond to so please do if you have any interest in membrane or remember at all.

I'm looking forward to working with Rob and to help keep membrane and remember moving forward!

collective.securitycleanup - GenericSetup handlers to restore Zope security to defaults

ross — 2008-12-01T18:25:30Z

WARNING: Backup your ZODB before using this package!

The Zope 2 security framework is very powerful and one of it's greatest strengths. A lot of it's power comes from it's flexibility. Exposing that power to site adminsitrators often ends up giving them enough rope to hang themselves with. This is exactly what the "Security" tab in the ZMI does.

In many cases, a site admin or consultant is faced with the daunting task of restoring all the security settings throughout the Zope object heirarchy in order to bring sanity and predictability back to the site. The collective.securitycleanup package provides GenericSetup handlers for restoring the role mappings and local roles back to their defaults. This handler can be used in combination with existing handlers to set role mappings and to re-apply workflow security settings to help start the process of security cleanup.

The clean up is performed on all ancestors including the Zope application root and by walking down the heirarchy to all descendants. This means all descendents of the context the handler is used on and all ancestors of the context including the root will be cleaned up. It will not clean up siblings or anything else that is not a direct ancestor to the context.

The clean up removes all permission settings stored on the instance which effectively restores them to code defaults. The clean up also removes all local roles except the "Owner" role for the user returned by OFS.interfasces.IOwned.getOwnerTuple() if already assigned.

Use of this tool will likely only ever be a starting point. So be sure to test thoroughly before deploying to your production server and backup your ZODB before using it.

collective.catalogexport - Use ZCatalogs as export sources

ross — 2008-11-15T04:36:58Z

The data contained in tabular form in ZCatalogs is often exactly the data site admins frequently want to export into some other format, such as CSV. This package provides views for exporting the catalog data into various formats.

Currently, only exporting the whole catalog with all metadata/brains/columns as CSV is supported. I plan to add support for submiting arbitrary index queries and for controlling the metadata/brains/columns exported.

collective.slideshowfolder - Somtimes useful extensions to Products.slideshowfolder

ross — 2008-11-13T06:27:28Z

The SlideshowImage content type uses a reference to an existing normal image somewhere else in the site to act as a kind of link or alias. This allows for the creation of a folder as a slideshowfolder that displays images that are actually stored elsewhere.

collective.redirect - Administer redirects to internal or external URLs using Link like content

ross — 2008-11-12T04:55:41Z

Administer redirects to internal or external URLs using Link like content. Where Products.redirectiontool or plone.app.redirector only deal with redirecting to internal URLs internal to the portal, collective.redirect allows for redirecting to external URLs. The paths to redirect are administered using instances of the Redirect content type. The paths that are redirected are independent of the path of the Redirect instance for a couple of reasons.

Firstly, since the portal object is not a BTree based folder it will begin to behave poorly if too many objects are added to it. Allowing the redirected paths independent from the location of the Redirect instances allows for many redirects without putting too many objects in the portal root.

Secondly, having the paths independent of the Redirect instance locations allows users to create redirect for paths that they can't add content too. Keep in mind that this might be a bad thing for your site and can certainly be abused as a DOS attack of sorts.

If multiple redirects exist for the same path, the one with the more recent publication date will be preferred. Finally a redirect will never override an otherwise traversable URL. IOW, a redirect cannot override an actual content object, skin object, view, or anything else traversal. The redirect only occurs when a NotFound error would otherwise be raised.

collective.formcriteria - User enterable search criteria forms for collections/topic/smart folders.

ross — 2008-05-24T20:49:18Z

This package provides new criteria types based on the
ATContentTypes.criteria types that are used to create a form at the
top of the topic view. Users can use the form to submit criteria to
supplement any search criteria in the topic. Values entered on the
criteria tab for the topic become the default values on the form.

Also provided is an alternative display layout that uses the folder
contents table and can still display the search form viewlet.

See the PyPI page for more details.

collective.testcaselayer - Use test cases as zope.testing layers

ross — 2008-05-24T06:19:53Z

The support for layers provided by zope.testing helps to lessen the amount of time consumed during test driven development by sharing expensive test fixtures, such as is often requires for functional test. This package provides several well tested facilities to make writing and using layers faster and easier.

Layer authors often end up reproducing the functionality provided by their test case classes since the same functionality is needed to perform layer set up or tear down. The collective.testcaselayer.ztc, collective.testcaselayer.ctc, and collective.testcaselayer.ptc modules provide layer base classes that mix in the test case functionality from ZopeTestCase, CMFTestCase, and PloneTestCase, respectively. See the collective.testcaselayer.ztc, and collective.testcaselayer.ptc sections below (or ztc.txt and ptc.txt if reading this in the source) for more details. These layer base classes also include the layer base class support from collective.testcaselayer.layer and the sandboxed ZODB layer support from collective.testcaselayer.sandbox described below. Additionally, these modules allow for using the test case fixtures as layers themselves.

While class objects can be used as layers, as opposed to instances of classes, doing so means that it is not possible for a layer to subclass another layer *just* to re-use functionality without also depending on that layer being set up as well. See the collective.testcaselayer.layer section below (or layer.txt if reading this in the source) for more details.

The DemoStorage included with the ZODB provides a way to "nest" ZODB stores such that all writes will go to the DemoStorage while reads will be taken from the base storage if not available from the DemoStorage. The collective.testcaselayer.sandbox module uses this feature to associate a DemoStorage with each sandboxed layer to which set up changes are committed and restore the base storage on tear down. Thus sibling layers that write to the ZODB can be isolated from each other. See the collective.testcaselayer.sandbox section below (or sandbox.txt if reading this in the source) for more details.

See the PyPI page for more details.

rpatterson.mailsync - OfflineIMAP, mswatch, and Gnus integration for realtime mail

ross — 2008-05-01T08:17:30Z

Like many others I've been frustrated with the options that are available for email clients. I recently had a bit of break through and packaged the reusable parts of my mail setup for consumption by others. See the backstory for all the gory details of the hisotry. I've factored everything with an eye towards extensibility so if there's enough interest, I'll start a project and a public repo somewhere and put this out there. See the TODO list if your interested in any of the ideas I have for improvements.

To try it out, just see the README on the pypi page. Here's a brief description.

This package provides some scripts that wrap parts of mswatch and
OfflineIMAP and integrate with Gnus to provide a local maildir that
is synchronized with a remote maildir as changes occur, instead of
polling on a regular basis. This provides for near instant delivery
of new mail while also reducing resource utilization. Integration
with the Emacs mail and newsreader, Gnus, is also provided in such a
way that your single threaded Emacs process is blocked much less as
changes occur to the maildirs.

z3c.persistentfactory - Persistent instance method ZCA factories

ross — 2008-04-09T06:43:26Z

Homepage: http://pypi.python.org/pypi/z3c.persistentfactory

The ZCA and the ZODB are a good combination where components require persistent state. ZCA factories or handlers typically retrieve any persistent state required from the persistent objects being adapted. If the persistent state required is not specific to the objects being adapted, a common solution is to register a persistent utility which is then looked up in the factory or handler. The persistent utility approach requires, however, that the one appropriate utility is looked up which requires support in the ZCA registrations either in the interface provided or the utility name.

In some cases, however, it is more consistent with the object oriented semantics of Python and the ZCA to think of the factory or handler as an instance method of a persistent object. With this approach the non-context specific persistent state can be accessed on self.

Instance Method Event Handler

One example where this may be useful is where some non-context persistent state is tightly coupled to some event handlers in such a way where instance methods are better semantics.

The Baz class uses the decorator in the python code. Note that the factory decorator must come before the declaration decorators so that it will be run last and will reflect the declarations.

>>> from z3c.persistentfactory import testing
>>> baz = testing.Baz()

>>> from zope import component
>>> component.provideHandler(factory=baz.factory)

The method adapts IFoo, so create an object providing IFoo to be used as the event.

>>> component.adaptedBy(baz.factory)
(<InterfaceClass z3c.persistentfactory.testing.IFoo>,)

>>> from zope import interface
>>> foo = testing.Foo()
>>> interface.alsoProvides(foo, testing.IFoo)

When the event is notified, the method is called with the event as an argument.

>>> import zope.event
>>> zope.event.notify(foo)
Called <bound method Baz.factory of
<z3c.persistentfactory.testing.Baz object at ...>>
  args: (<z3c.persistentfactory.testing.Foo object at ...>,)
  kwargs: {}

Instance Method Adapter Factory

Another example is where an adapter factory needs to look up persistent state specific to the objects being adapted but where that state can't be stored on the adapted objects them selves. The component storing the shared persistent state can register one of it's instance methods as the adapter factory which will look up the necessary persistent state on self.

>>> component.provideAdapter(factory=baz.factory)

The method implements IBar.

>>> tuple(interface.implementedBy(baz.factory))
(<InterfaceClass z3c.persistentfactory.testing.IBar>,)

When the adapter is looked up, the metod is called with the object to be adapted as an argument.

>>> result = component.getAdapter(foo, testing.IBar)
Called <bound method Baz.factory of
<z3c.persistentfactory.testing.Baz object at ...>>
  args: (<z3c.persistentfactory.testing.Foo object at ...>,)
  kwargs: {}
>>> result
(<bound method Baz.factory of
 <z3c.persistentfactory.testing.Baz object at ...>>,
 (<z3c.persistentfactory.testing.Foo object at ...>,), {})

z3c.gibberish - CSV files of random dictionary words

ross — 2007-12-21T00:46:34Z

I needed to generate random verbiage that still reflected indexing performance somewhat realistically for a JMeter test plan I built for a project with Jazkarta. As such, I wanted something other than random strings, I wanted real words but random selection. I wrote z3c.gibberish to do this.

There are a couple improvements I'd like to make to z3c.gibberish given interest and time:

Weighted Word Frequency

I'd like to improve z3c.gibberish to use a weighted random selection so that more common words are selected more often.

On further thought, it would probably be best to support this by using a dictionary that repeats words to represent frequency. Maybe z3c.gibberish could be extended to take a normal dictionary and a file representing weights and output a weighted dictionary to be used for subsequent runs of z3c.gibberish.

Optimized Row Handling

I could also make it more efficient by pre-assembling a list of dictionary indexes for each row and then assembling the row by retrieving the words corresponding to the index in order to avoid repeatedly iterating through the dictionary for each row/cell.

z3c.recipe.ldap - deploy an OpenLDAP server

ross — 2007-12-21T00:47:13Z

z3c.recipe.ldap is a zc.buildout recipe I wrote for Jazkarta while working on an internet startup project. It can be used to deploy an OpenLDAP server. More specifically it provides for initializing an LDAP database from an LDIF file and for setting up an LDAP instance in the buildout. This recipe can also be used to provide an isolated LDAP instance as a test fixture.

I'd like to complete z3c.recipe.subprocess and port this package to that. It does, however, work just fine now.

zc.buildout - Contributed fixes

ross — 2007-12-21T09:21:38Z

I've contributed fixes to zc.buildout.

Products.CMFPlacefulWorkflow - GenericSetup export and import handlers

ross — 2007-12-21T00:11:28Z

I contributed CMFPlacefulWorkflow export and import handlers for the HRN project with Jazkarta.

z3c.recipe.egg - working with source distributions

ross — 2007-12-21T00:47:03Z

z3c.recipe.egg provides recipes based on zc.recipe.egg for working with source distributions.

Editable Distributions

The z3c.recipe.egg:editable recipe uses the easy_install --editable and --build-directory options to download multiple source distributions.

The source distributions will be placed in the part directory and managed by the buildout if build-directory is not specified. If so, the distributions will be replaced when newer versions are available. So be sure to set build-directory to a directory not managed by buildout if you want to maintain changes to the source distributions.

The z3c.recipe.egg:editable can be used to assemble a set of subversion checkouts to work with specifying subversion URLs in find-links as is supported by easy_install. See the easy_install documentation for the syntax for using subversion URLs. There are a number of ways in which it is more flexible to control checkouts via recipes rather than svn:externals.

Finally, if the develop option is true then the distributions will be installed in develop mode.

See z3c/recipe/egg/editable.txt for more details.

Running Setup Scripts

The z3c.recipe.egg:setup recipe calls arbitrary setup.py commands on multiple distributions in a buildout.

The z3c.recipe.egg:setup recipe can be used, for example, to automate releases. When the source is ready for release, the setup recipe is configured to run the "register sdist bdist_egg upload" setup commands. To ensure release only runs when intended, the setup recipe can be used in it's own release.cfg file that extends the buildout.cfg file. With this setup, releases for multiple projects can be made with "bin/buildout -c release.cfg".

The z3c.recipe.egg:setup recipe also supports the develop option as with z3c.recipe.egg:editable.

See z3c/recipe/egg/setup.txt for more details.

z3c.repoexternals - Generate svn:externals from trunks in a repository

ross — 2007-12-21T00:47:30Z

z3c.repoexternals recursively retrieves subversion directory listings from the url or path and matches directories against a previous set of svn:externals
if provided then against regular expressions and generates
qualifying svn:externals lines. The defaults generate a set of
svn:externals for all the trunks in a repository and keeps them up
to date with the repository as new trunks are added when the
previous externals are provided thereafter.