Personal tools
Skip to content. | Skip to navigation
borg python module
This PAS_ plug-in can be used to assign local roles in a particular context, by adapter. It can be installed via the GenericSetup_ profile in this product.
Dump buildout picked versions.
Q: What is a buildout extension ? A: http://pypi.python.org/pypi/zc.buildout#extensions The problem When developing zope/plone eggs with buildout I have to edit the buildout configuration file ( in 3 places ) each time I create/delete/rename a development egg in the src directory or in other development directories (sometime I have more than one). I have to add/delete/rename the egg in the eggs option of the [buildout] and then add/delete/rename the egg path in the develop option of the [buildout] and in the end add/delete/rename the zcml option of the zope [instance] or in the configure.zcml file of my policy package. This is too much specially when the speed is set to development mode. I need a less boring way to develop. Solution buildout.eggtractor is a buildout extension that scans the src directory or a list of directories I give for eggs and picks them up automatically. So no more editing of the buildout's configuration file. When buildout.eggtractor finds an egg in the scanned directory it: 1. adds the egg to the ``eggs`` option of all zope instance parts or to a set of given parts 2. adds the egg's path in the ``develop`` option of the ``[buildout]`` 3. If ``tractor-autoload-zcml`` is not given or set to other thing than false, scans the egg folder for ``configure.zcml``, ``meta.zcml`` and ``overrides.zcml`` and adds the appropriate zcml entries to the ``zcml`` option of the zope instance parts or to a set of given parts. This steps are done on the fly when running buildout. So I can add/delete/rename an egg and it will be picked up. NOTE: The extension does not write to the buildout's configuration file. buildout.eggtractor options tractor-src-directory: A set of directories to scan for development eggs. Defaults to the src directory of the buildout. tractor-target-parts: A set of parts to update their eggs option with eggs found in the tractor-src-directory. Defaults to zope instance parts if any. tractor-autoload-zcml(boolean): Update the zcml option of tractor-target-parts with the eggs found in tractor-src-directory. Defaults to true tractor-zcml-top: A set of eggs to load their zcml files first. Defaults to an empty set. How to use it Using buildout.eggtractor is very simple. As said, it is a buildout extension. All I have to do is to declare it in the extensions option: [buildout] parts = extensions = buildout.eggtractor That's all. buildout.eggtractor will scan the src directory and do its job every time I run the buildout command. When I have other directories I want to scan I just add an tractor-src-directory option in the [buildout] and add my directories there: [buildout] parts = extensions = buildout.eggtractor tractor-src-directory = dev-src1 dev-src2 src In a few cases when the priority of loading zcml files matters. I add the egg to be loaded first in the tractor-zcml-top option in the [buildout]: [buildout] parts = extensions = buildout.eggtractor tractor-src-directory = dev-src1 dev-src2 src tractor-zcml-top = plone.app.mypackage1 If I want to add the eggs found in the development directories to the eggs option of a given set of parts, I add a tractor-target-parts option and add the parts there: [buildout] parts = instance1 instance2 instance3 extensions = buildout.eggtractor tractor-target-parts = instance1 instance3 This way only instance1 and instance3 will be updated. If I have already other way to include the zcml files (ie: z3c.autoinclude) and don't want eggtractor to generate the zcml slugs, I add an tractor-autoload-zcml option and set it to false In most cases you will only need to add buildout.eggtractor to the extensions option of the [buildout] without any extra configuration options. LIMITATION The extension assumes that the egg name reflects its file system structure example: if the egg name is com.mustap.www the extension assumes that the file system structure is one of the following: 1. com.mustap.www/src/com/mustap/www 2. com.mustap.www/com/mustap/www This is where the extension looks for configure.zcml, meta.zcml and overrides.zcml files. If the egg name has nothing to do with how it is structured on the system, the extension will ignore it. XXX: I guess walking through the directory is better than this assumption. In my case this is not a limitation as I choose my egg names that way.
catdoc is program which reads one or more Microsoft word files and outputs text, contained insinde them to standard output. Therefore it does same work for.doc files, as unix cat command for plain ASCII files. It is now accompanied by xls2csv - program which converts Excel spreadsheet into comma-separated value file, and catppt - utility to extract textual information from Powerpoint files
Simple Google analytics integration for Singing & Dancing Adds tracking parameters to urls in outgoing S&D newsletters. See browser.txt for more in depth info. Note for translators: Titles and descriptions for the configuration ui can be lifted from http://www.google.com/support/analytics/bin/answer.py?hl=en&answer=55578 in almost any language.
This product implements Cory LaViska's 'JQuery Alert Dialogs' for Plone. Basically, they are fancy, styleable replacements for the standard 'alert', 'confirm' and 'prompt' browser functions. Please see: http://abeautifulsite.net/notebook/87 for more information. Usage ----- When collective.alerts is installed and the jquery.alerts library registered in portal_javascripts (should be automatic), then the alerts can be called as follows: - jAlert( message, [title, callback] ) - jConfirm( message, [title, callback] ) - jPrompt( message, [value, title, callback] )
How to create new tour First of all you need to define the tour. Starting version 1.1 we are using configuration based style. A tour is a .cfg file. It has an amberjack main section which has two options: title and steps - this is where you define tour steps: [amberjack] steps = my_step1 my_step2 title = My first amberjack tour there are also available two blueprints: 1. Step a step section is defined by collective.amberjack.blueprints.step and has several options: * title * text * url - step url definition * xpath - xpath selector * xcontent - xcontent selector * microsteps - microsteps sections * validators - tales expression validation it looks like that: [my_step1] blueprint = collective.amberjack.blueprints.step title = This is my first Step text = You should now know how to create a step section url = /mystep validators = python: context.isFolderish() xpath = '' xcontent = '' microsteps = microstep_1 microstep_2 2. Microstep a microstep section is defined by collective.amberjack.blueprints.microsteps and it has several options: * idstep * text * description * selector it looks like that: [microstep_1] blueprint = collective.amberjack.blueprints.microstep idstep = menu_state text = This is my dummy microstep description = Now you should now how to define microsteps selector = #insert Tour registration Finally you have to register it. The only acceptable format is an archive (zip or tar) which contains one or multiple .cfg files (tours) Using zcml: <configure xmlns:collective.amberjack="http://namespaces.plone.org/collective.amberjack.core"> <collective.amberjack:tour tourlocation="mytourpackage.zip" /> </configure>