Now Viewing: cogbin
Presentation
TurboGears 2 is rapid web application development toolkit designed to make your life easier.
-
Applications written for Turbogears
When you quickstart a TurboGears project, the setup.py file already contains the metadata you need. It's just commented out. Choose the right keywords for the kind of project you're releasing, and you're all set. Below you will find the sample code and the table below has the keywords you should use. TurboGears packages added to the Python Package Index will automatically appear in the CogBin!
keywords = [ 'turbogears2.application' ],Add this keyword to your setup.py before uploading to PYPI.
Keywords:turbogears2.widgets turbogears2.command turbogears2.application turbogears2 turbogears.widgets turbogears.extension turbogears.command turbogears.application turbogears tg2 repoze python.templating.engines pylons -
turbogears2.widgets
Package Name Version Summary Author Description -
turbogears2.command
Package Name Version Summary Author Description -
turbogears2.application
Package Name Version Summary Author Description cogbin 0.2.11dev Cogbin is a webtool that sync with pypi, it retrives metadata from it and displays the categories you set up in its web interface. It is running for turbogears2 with turbogears2 categories by default but these can be adjusted at any time. Install it, modify the categories, deploy and you have a list of packages for your software community. Lukasz Szybalski UNKNOWN -
turbogears2
Package Name Version Summary Author Description tgext.geo 0.6.3 TurboGears Extension for Geographic Applications Sanjiv Singh UNKNOWN -
turbogears.widgets
Package Name Version Summary Author Description tgcurvycorners 0.1.1 A TurboGears Widget to help use curvycorners Florent Aide UNKNOWN tgMochiKit 1.4.2 MochiKit packaged as TurboGears widgets. Diez B. Roggisch UNKNOWN TurboTinyMCE 1.0.6 TinyMCE widget for TurboGears Alberto Valverde Gonzalez UNKNOWN TGPriFlash 0.1.2 A TurboGears flash implementation that supports multiple priority levels. Chris Miles TGPriFlash is a TurboGears flash implementation that supports multiple priority levels. Install ------- Install with setuptools:: $ easy_install TGPriFlash or download from http://pypi.python.org/pypi/TGPriFlash Usage ----- Out of the box, 3 levels are defined (FLASH_INFO, FLASH_WARNING, FLASH_ALERT) but you can ignore these and use any integer values you like as the flash priority levels. To "magically" replace (aka monkey patch) turbogears.flash() with this one, just add this import to your start-project.py:: import tg_pri_flash.flash Within your project you can import turbogears.flash as normal:: from turbogears import flash You'll want to replace the tg_flash line in your master template:: <div py:if="tg_flash" class="flash" py:content="tg_flash"></div> with something like this:: <div py:if="tg_flash and tg_flash[1]==0" class="flash_ok" py:content="tg_flash[0]"></div> <div py:if="tg_flash and tg_flash[1]==1" class="flash_warning" py:content="tg_flash[0]"></div> <div py:if="tg_flash and tg_flash[1]==2" class="flash_alert" py:content="tg_flash[0]"></div> You would then define CSS definitions for each of the classes. In your controller you can call flash() with a second argument, a positive integer:: flash( _(u"There was an error"), 2 ) or, using the built-in constants:: from tg_pri_flash.flash import FLASH_ALERT flash( _(u"There was an error"), FLASH_ALERT ) ConfigAdministrator 0.1a1.dev-r2011 UNKNOWN UNKNOWN UNKNOWN TGIXEDIT RC Ixedit Michele Diegoli Ixedit: the first on-the-fly interaction design tool 4 web now for turbogears... as a widget! TGFKLookup 0.1a0.dev-r1772 A collection of widgets to do Foreign Key related lookups Claudio Martinez Still a work in progress. AutoCompletingFKLookupField, it's a prototype based rewrite of the autocompleting TG widget. It allows lookup by ID and text search and shows both fields. Check the widget browser for a demo. UpdatableSingleSelectField receives a function on the opt_feeder param and will setup a controller automagically to update it when the .update() javascript method from the manager is called. I'm currently using it to make options lists based on other fields. Also takes a predicate if you want to protect the Ajax calls. Demo coming soon. TGExpandingFormWidget 0.1.3 This module provides a dynamically expandable form widget for TurboGears. Chris Miles TGExpandingFormWidget is a type of repeating form widget for TurboGears. It contains groups of widgets which are repeated on the page. The user is able to dynamically add or remove widget groups as required before submitting the form. This widget is based on dynwidget by Randall Smith. It has been cleaned up and bug-fixed by Chris Miles and released with Randall's permission. TGCaptcha 0.11 A TurboGears CAPTCHA widget for forms. Patrick Lewis TGCaptcha is a TurboGears widget that provides an easy way to incorporate a captcha as part a form in an attempt to reduce spam or malicious activity. Features include: * (Relatively) pain-free usage and validation inside of a regular widget-based form * Flexibility to add or extend image generation algorithms and the text displayed in the image Scriptaculous 1.8.2 Scriptaculous packaged as TurboGears widgets. Thomas Fuchs, Sam Stephenson, Kevin Dangoor, Fred Lin, W-Mark Kubacki UNKNOWN TGYUI 2.5.0 The Yahoo! YUI packaged as collection of TurboGears widgets. W-Mark Kubacki, Marco Mariani, Lulamile Mzamo UNKNOWN TGExtJS 0.2.3b ExtJS packaged as collection of TurboGears widgets. W-Mark Kubacki UNKNOWN TGOpenIDLogin 0.1 OpenID login controller for TurboGears Neil Blakey-Milner UNKNOWN TGScheduler 1.6.1 Turbogears Scheduler Vince Spicer This scheduler that is based TG1's scheduler which was based on Kronos by Irmen de Jong. This scheduler makes it easy to have one time or recurring tasks run as needed submodal 1.5 Cross Browser DHTML Modal Dialogs For Web Apps Jorge Godoy (packager) The subModal works by placing a semi-transparent div over the browser, blocking access to the content below while still providing visibility. This maintains state and doesn't make someone feel disoriented or lost by moving them completely to another page. Their frame of reference is kept while allowing them to perform a new task (usually closely associated with the content below). This version was based on the enhanced subModal provided by Todd Huss. jquery 1.2.3 Jquery javascript library for TurboGears Fred Lin Feature =============== jquery is a jquery javascript library wrapper and ajax helper for happy TurboGears web designers. Available widgets ==================== * Jquery (basic jquery libray wrapper for Turbogears) It also contains 3 extra ajax widgets based on jquery. * addCallback / link_to_remote(target ,update, href, callback) * addPeriodBack / periodically_call_remote(update, href, interval) * addFormback / form_remote_tag(target, update, href) Which are inspired from Ruby on Rails/pquery and give them the twisted syntax. Install ============== Use setuptools to install:: $easy_install jquery Usage ============== jquery ~~~~~~~~~ include in config/app.cfg:: tg.include_widgets = ['jquery.jquery'] jquery ajax usage: ~~~~~~~~~~~~~~~~~~~~~ import in controllers.py:: from jquery import addCallback from jquery import addPeriodback from jquery import addFormback .... return dict(addCallback = addCallback, addPeriodback = addPeriodback, addFormback = addFormback) .. note:: Update notice form 1.1.2 jquery widget: you need return dict(link = addPeriodback) instead of return dict(link = addPeriodback()) in the following versions in template:: [div id="timelink"][a href = "#"]get time[/a][/div] [div id="timediv"][/div] ${addCallback(target="timelink" ,update="timediv", href="/time")} .. note:: With genshi template, you should add 'ET' prefix before the callback, such as:: ${ET(addCallback(target="timelink" ,update="timediv", href="/time"))} or:: [div id="timediv"][/div] ${addPeriodback(update="timediv", href="/time", interval="3000")} or:: [form class="timelink" action="ajax" method="get" ] Field : [input type="text" name="field" /][br /] [input type="submit" /] [/form] [div id="timediv"][/div] ${addFormback(target="timelink", update="timediv", href="ajax")} .. note:: The addCallback/addPeriodback/addFormback call could be placed anywhere in your template. Check http://docs.turbogears.org/1.0/RemoteLink for detail. Reference ============ - jquery http://jquery.com - pquery http://www.ngcoders.com/pquery/ Source ============ Source is available in http://svn.turbogears.org/projects/tgJquery/trunk History ============= 1.2.3: * update to jquery 1.2.3 * host in TurboGears svn 1.2.2: * update to jquery 1.2.2 1.1.2w2: * new twisted style ajax call * new addFormback/form_remote_tag call * passing ajax function no need extra '()' at all. AccordionWidget 0.1 An accordion widget for TG framework Luigi S. Palese Turbogears porting of Minikit makeAccordion javascript function. (Requires updating to MochiKit 1.4) FileFields 0.1a7.dev-r2292 File and Image upload fields for forms. Claudio Martinez Right now this package provides 2 widgets, FileField and ImageField. These widgets support file uploading with server side caching. That means that if some other field in the form fails validation, the user wont have to upload the file again. Instead they get the information of the file they included or a thumbnail of the image if it's an ImageField. An option to remove the file from the form is given too. The ImageField has a thumbnail preview and allows size validation and automatic resizing when dimensions get past certain values (this isn't enabled by default). If Lightbox is installed (optional), the full size images will be displayed with it (non popup image viewer). Also an animation removing the file attached to the form will be shown if Scriptculous is installed (optional). The server side caching is done using the TemporaryFile class from the official Python tempfile module. It's a secure way to store files on a platform independent way. The files are cleared when they are not used anymore. The widgets need a controller that will be the file server for the download links and images previews. You can import the controllers from file_fields.controllers (PicServer and FileServer) and specify the url on the widget constructors (file_server_url, image_server_url) The easiest and recommended way is enabling the extension your dev.cfg, prod.cfg or app.cfg adding: file_field_server.on = True tg_interface 1.2-0.01 jquery library for TurboGears Derek Anderson Feature =============== tg_interface is a interface javascript library wrapper and ajax helper for TurboGears web designers. Available widgets ==================== * tg_interface (turbogears interface plugin) Install ============== Use setuptools to install:: $easy_install tg_interface Usage ============== tg_interface ~~~~~~~~~ include in config/app.cfg:: tg.include_widgets = ['tg_interface.tg_interface'] Reference ============ - tg_interface http://interface.eyecon.ro/ DisplayShelf 1.0 The Flex Display Shelf James Ward and Kevin Dangoor The Display Shelf renders images in a fancy shelf similar to the iTunes 7 album art display. One image is in front with a flat perspective, while the other images are slanted to the sides of the selected image. The Display Shelf was written by Ely Greenfield, licensed BSD, and built with the free Flex SDK. The Display Shelf is compiled to Flash byte code and requires the client to have Flash 9. You can find the source code and more information about the Display Shelf at: http://www.quietlyscheming.com/blog/components/tutorial-displayshelf-component/ For more information on using this component, visit: http://www.jamesward.org/wordpress/2007/01/20/flex-and-turbogears-at-codemash-displayshelf-widget/ checkboxtable 0.80 A table of checkboxes Chris Cioffi Like a CheckboxList, this widget allows the user to display mutliple checkboxes with associated data. Unlike a CheckboxList, it allows you to use mutliple data elements to describe each item. Most of the CSS is stolen verbatim from the DataGrid widget, I just changed the class to checkboxtable so people could use both data grids and checkboxtables without conflicts. Long term I would like to add Javascript to allow some of the cool mutliselect goodness that the GMail inbox shows. :) MultiComplete 1.0 Multiple word completion within a single text field TG widget. Hakan Bilgin, Kevin Dangoor UNKNOWN TurboFancyFlash 0.1a TurboGears extension providing enhanced flash message display functions. Christopher Arndt This package provides an enhanced version of the ``turbogears.flash()`` function, giving your users much nicer-looking message boxes that can change their appearance based on the status of the message. With JavaScript enabled, messages can fade out after a timeout or be dismissed by the user with a mouse-click. This is accomplished by encoding the message with JSON and decoding it again in the template of the target page. This is handled completely automatic and the programmer can just use the functional interface, e.g. ``fancyflash.error("Duh!")``. Additionally, you can display messages with a simple JavaScript function call, for example when processing the results of an AJAX call in your callback function for ``loadJSONDoc``. For more information see the source of the ``fancyflash`` package, the epydoc-generated `API documentation`_ and the FancyFlashExample_ application. Installation ------------ To install TurboFancyFlash from the Cheeseshop_ use `easy_install`_:: [sudo] easy_install TurboFancyFlash This requires the setuptools_ package to be installed. If you have not done so already, download the `ez_setup.py`_ script and run it to install setuptools. Usage ----- Controller (``controllers.py``):: # Import TurboGears from turbogears import controllers, expose, redirect, validate, validators # Import fancyflash package import fancyflash as ff # Set the default timeout for message box display ff.set_default_flash_timeout(5) # Let FancyFlashWidget be included on every page ff.register_flash_widget() class FlashTestController(controllers.Controller): @expose('templates.welcome') def index(self, timeout=0): return {} @expose() def info(self): ff.info("Hello TurboGears!") redirect('/') @expose() @validate(validators=dict(timeout=validators.Int)) def success(self, timeout=0, tg_errors=None): ff.success("Hello TurboGears!", timeout) redirect('/') @expose() @validate(validators=dict(status=validators.String)) def message(self, status="info", tg_errors=None): ff.statusmessage("Hello TurboGears!", status) redirect('/') Master template (``master.kid``):: <div id="main_content"> <div py:replace="tg_fancyflashwidget(tg_flash)">Status message appears here</div> <div py:replace="[item.text]+item[:]"/> ... </div> Acknowledgments --------------- The idea for this widget is based on a `blog post`_ by Lee McFadden: .. _blog post: http://www.splee.co.uk/2005/11/23/fancy-status-messages-using-tg_flash/ Todo ---- * Test in IE * Test opacity in Safari If I have time: * Add argument for dialog position (implement by writing CSS dynamically). * Round boxes for non-Gecko browsers * Add AJAX widget, which displays result of ``loadJSONDoc`` as fancy status message. .. _api documentation: http://chrisarndt.de/projects/fancyflash/api/index.html .. _fancyflashexample: http://chrisarndt.de/projects/fancyflashexample/ .. _cheeseshop: http://cheeseshop.python.org/pypi/TurboFancyFlash .. _setuptools: http://peak.telecommunity.com/DevCenter/setuptools .. _easy_install: http://peak.telecommunity.com/DevCenter/EasyInstall .. _ez_setup.py: http://peak.telecommunity.com/dist/ez_setup.py TGSociable 0.1.0 A port of the sociable Wordpress plugin Neil Blakey-Milner, Peter Harkins (original sociable plugin for wordpress) TurboGears Widget to add links to post pages to social bookmarking sites (Digg, Reddit, del.icio.us, &c.) dynwidgets 1.1 TurboGears widget to automatically replicate a list of other widgets (or a FieldSet or ...), including 'add' and 'remove' buttons Jorge Godoy This widget was based on a quickstarted project posted to the TurboGears mailing list (http://groups.google.com/group/turbogears/browse_thread/thread/148053c87b5c42e8/d2e9a7508d8c85dd?lnk=gst&q=&rnum=19) and encapsulated as a TurboGears widget for better reuse. TGFusionCharts 0.1 FusionCharts widget for TurboGears Nadav Samet Easily create eye-catching flash charts with this widget. DOMinclude 1.0.1 TurboGears widget that wraps the DOMinclude library for DOM-based popups. Christian Heilmann, Kevin Dangoor This is a TurboGears_ widget project that wraps the DOMinclude_ JavaScript library for DOM-based popups. You can view the widgets in the TurboGears Toolbox_. For further information, visit the `DOMinclude widget homepage`_. .. _turbogears: http://www.turbogears.org .. _dominclude: http://onlinetools.org/tools/dominclude/ .. _toolbox: http://docs.turbogears.org/1.0/Toolbox .. _dominclude widget homepage: http://docs.turbogears.org/tgDOMinclude RssWidget 0.2.1 beta Turbogears RSS Widget Bogdan Hlevca This is a very simple RSS aggregator implemented as a Turbogears widget, which is using Mark Pilgrim's Universal Feed Parser as the underlying feed parser. Added exception handler for bad feeds spinner 1.0 TurboGears Spinner Widget Abhishek Kumar UNKNOWN Select-Shuttle 1.3.3 The SelectShuttle widget provides a mechanism for selecting multiple values from a list of values by allowing the user to move items between two lists. On modern browsers you can also double click an item to move it from one list to the other. After the first "move", all entries will be sorted automatically accordingly to its "description" on both lists. Take a look at the code for SelectShuttleDesc for an example of how to use this widget in your code. Jorge Godoy UNKNOWN UPCTools 0.1a1 A online checking UPC field and a lookup tool Claudio Martinez On early stages. Uses the XMLRPC service from the online UPC Database to get the information. TGPaginate 0.1a0.dev-r2681 Pagination utilities for TurboGears Claudio Martinez Still a work in progress. This is a branch from the TG paginator that allows multiple paginations and support for Ajax. Right now it's focused on AjaxPaginatedGrid, it's a new widget that interacts with the pagination decorator to provide fast access to the data and interaction with other scripts. Check the widget browser for a demo. Uses Prototype. Tested and works with Opera, FireFox and IE6 (please report how it behaves with other browsers). InPlace 0.1a0.dev-r1518 Wrapper for the InPlace javascript library Claudio Martinez Still a work in progress. This is a javascript library I've been developing to allow in place editions of arbitrary DOM objects. It doesn't do any AJAX by itself but allows the attachment of hooks that can do it. For the input fields it uses a javascript widget system that will allow complex ones to develop. Right now there are available the text field and single selector widgets. Uses Prototype right now, but I might do it "library" agnostic. Works with Opera and Firefox, fails with IE (I don't know when I'll fix it, it's far from being a priority on the project I'm currently working). Check the widget browser! xcbl 0.2 Extensible CheckBoxList widget for TurboGears Catherine Devlin List ends with an 'Other:' element that can be filled in by hand. Any number of new options can be specified. MochiKit 1.4 required for optimal appearance. jsDOMenu 0.1a0.dev-r1765 A wrapper for jsDOMenu Claudio Martinez On early stages. The jsDOMenu library is GPL. addremoveoptions 1.0 Turbogears widget that creates a selectbox in which you can add and remove options Abhishek Kumar UNKNOWN TGLightWindow 2.0 LightWindow JS packaged as TurboGears widget W-Mark Kubacki UNKNOWN TGBooleanFormWidget 0.1 A yes/no or confirm/cancel input widget for TurboGears projects. Chris Miles This module provides a BooleanForm class, which acts like widgets.Form, except that it displays two submit buttons, one for confirming the action, the other for cancelling. TurboFeeds 0.2b TurboGears controller and widgets for feed handling. Christopher Arndt Turbofeeds is a TurboGears_ 1 extension which provides support for generating RSS and Atom feeds and matching display widgets. TurboFeeds was formerly the ``feed`` sub-package of the main TurboGears distribution. It was extracted from the TG core to ease updating, enhancing, and maintaining both projects. TurboFeeds is mostly backwards-compatible with the ``turbogears.feed`` package, but has lots of fixes and a few new features, most importantly support for Genshi templates. It works with both the TurboGears 1.0 and the 1.1 branch. Installation ------------ To install TurboFeeds from the Cheeseshop_ use `easy_install`_:: [sudo] easy_install TurboFeeds This requires the setuptools_ package to be installed. If you have not done so already, download the `ez_setup.py`_ script and run it to install setuptools. If you want to get the latest development version, you can check out the trunk from the `Subversion repository`_ with:: svn co http://svn.turbogears.org/projects/TurboFeeds/trunk TurboFeeds For bug reports and feature requests, please go to the TurboGears trac at http://trac.turbogears.org/. To open a ticket, you'll need a trac account. Please select "TurboFeeds" as the ticket component. Usage ----- Controller:: from turbogears import controllers, expose from turbofeeds import FeedController, FeedHeadLinks, FeedLinks class MyFeedController(FeedController): def get_feed_data(self, **kwargs): entries = [] # Fill ``entries`` with dicts containing at least items for: # # title, link, summary and published # # For example, supposing ``entry`` is a database object # representing a blog article: entries.append(dict( title = entry.title, author = dict(name = entry.author.display_name, email = entry.author.email_address), summary = entry.post[:30], published = entry.published, updated = entry.updated or entry.published, link = 'http://blog.foo.org/article/%s' % entry.id )) return dict(entries=entries) class Root(controllers.RootController): feed = MyFeedController( base_url = '/feed', title = "my fine blog", link = "http://blog.foo.org", author = dict(name="John Doe", email="john@foo.org"), id = "http://blog.foo.org", subtitle = "a blog about turbogears" ) feedlheadinks = FeedHeadLinks(controller=feed) feedlinks = FeedLinks(controller=feed, title = "Click link to access the feed in %(type)s format") @expose('.templates.mypage') def mypage(self): return dict( feedheadlinks=self.feedheadlinks, feedlinks=self.feedlinks) Template:: <head> ${feadheadlinks()} ... </head> <body> <h2>Feed links</h2> ${feedlinks('%(type)s feed', url_params=dict(format='full'))} ... </body> Documentation ------------- The TurboFeeds source is thoroughly documented with doc strings. The source distribution comes with epydoc-generated `API documentation`_ included. You can also refer to the documentation for the original ``turbogears.feed`` package on the TurboGears documentation wiki: http://docs.turbogears.org/1.0/FeedController All information on this page is also still valid for TurboFeeds, you just have to replace:: from turbogears.feed import FeedController with:: from turbofeeds import FeedController Credits ------- * The ``turbogears.feed`` package was first introduced in TurboGears version 0.9a1 and was added by Elvelind Grandin. * Christopher Arndt turned it into the TurboGears extension TurboFeeds. * Other contributors include: Florent Aide, Simon Belak, Kevin Dangoor, Charles Duffy, Alberto Valverde, Jorge Vargas Please notify the maintainer, if you think your name should belong here too. * The feed icons used by the CSS for the FeedLinks widget where taken from http://www.feedicons.com/. .. _turbogears: http://www.turbogears.org/ .. _cheeseshop: http://cheeseshop.python.org/pypi/TurboFeeds .. _setuptools: http://peak.telecommunity.com/DevCenter/setuptools .. _easy_install: http://peak.telecommunity.com/DevCenter/EasyInstall .. _ez_setup.py: http://peak.telecommunity.com/dist/ez_setup.py .. _api documentation: http://chrisarndt.de/projects/turbofeeds/api/index.html .. _subversion repository: http://svn.turbogears.org/projects/TurboFeeds/trunk#egg=turbofeeds-dev MochiInterpreter 1.3.1 This widget is an implementation of the interpreter example from MochiKit code. It is provided as a facility to develop TurboGears applications that needs JavaScript. It is based on code provided at http://trac.turbogears.org/turbogears/ticket/255 Jorge Godoy This widget is an implementation of the interpreter example from MochiKit code. It is provided as a facility to develop TurboGears applications that needs JavaScript. It is based on code provided at http://trac.turbogears.org/turbogears/ticket/255 TurboFlot 0.1.2 A TurboGears widget for Flot, a jQuery plotting library Luke Macken UNKNOWN PlotKit 0.9.1w3 PlotKit packaged as TurboGears widgets. Fred Lin PlotKit Javascript Chart Plotting packed as TurboGears Widget sgawidgets 1.0a ModalPopup Widgets collection Patricio Valarezo Lozano We need to wrap some libs to use javascripts under tg DivDialogs 0.1a1.dev-r610 A few dialogs (modal or not) to improve the UI usability of TurboGear apps Claudio Martinez On early stages. Uses the simple dimmingdiv.js library (with some modifications) to convert a DOM object specified by it's id on a dialog. TGFirebugLite 1.0b A TurboGears widgets wrapper for the Firebug Lite JavaScript Library. Christopher Arndt Installation:: [sudo] easy_install TGFirebugLite or: 1. Download the Egg manually from here_ or the Cheeseshop_. 2. Install with ``easy_install <egg-file>``. .. _here: http://chrisarndt.de/projects/tgfirebuglite/download/ .. _Cheeseshop: http://python.org/pypi/TGFirebugLite Usage: To use this widget, just add it to the ``tg.include_widgets`` configuration setting, for example in your ``dev.cfg``:: tg.include_widgets = ['firebug.widgets.firebug_js', ...] If you don't care to simulate the Firebug console, but you want to prevent calls to ``console.log()`` in your JavaScript code from causing errors, then just change the widget name to ``firebug.widgets.firebugx_js``. To try it out, just hit F12 after your page has loaded and the Firebug console frame will open at the bottom of your page. You can enter JavaScript commands at the command line right at the bottom and see their outcome in the console logging area above. Please see http://www.getfirebug.com/lite.html for more information. TGCombine 1.0.4 Turbogears Javascript/CSS Combine and Pack Vince Spicer UNKNOWN Lightbox 2.1 Lightbox photo display widget Lokesh Dhakar, Kevin Dangoor, Christopher Arndt This is a TurboGears_ widget wrapper for the Lightbox2_ JavaScript library by Lokesh Dhakar. You can view the widgets in the TurboGears Toolbox_. For further information, visit the `Lightbox widget homepage`_. .. _turbogears: http://www.turbogears.org/ .. _lightbox2: http://www.lokeshdhakar.com/projects/lightbox2/ .. _toolbox: http://docs.turbogears.org/1.0/Toolbox .. _lightbox widget homepage: http://docs.turbogears.org/tgLightbox checkselect 1.2 CheckSelect TurboGears Widget Jorge Godoy CheckSelect aims to solve a problem found with Multiple Select fields where it isn't possible to specify their widths, messing up with some layouts. It also aims to make selecting multiple choices easier and more accessible for users of your application. This is a widgetized version of Nicholas Rougeux code at http://c82.net/article.php?ID=25 that extends TurboGears' default CheckBoxList code. -
turbogears.extension
Package Name Version Summary Author Description TurboFancyFlash 0.1a TurboGears extension providing enhanced flash message display functions. Christopher Arndt This package provides an enhanced version of the ``turbogears.flash()`` function, giving your users much nicer-looking message boxes that can change their appearance based on the status of the message. With JavaScript enabled, messages can fade out after a timeout or be dismissed by the user with a mouse-click. This is accomplished by encoding the message with JSON and decoding it again in the template of the target page. This is handled completely automatic and the programmer can just use the functional interface, e.g. ``fancyflash.error("Duh!")``. Additionally, you can display messages with a simple JavaScript function call, for example when processing the results of an AJAX call in your callback function for ``loadJSONDoc``. For more information see the source of the ``fancyflash`` package, the epydoc-generated `API documentation`_ and the FancyFlashExample_ application. Installation ------------ To install TurboFancyFlash from the Cheeseshop_ use `easy_install`_:: [sudo] easy_install TurboFancyFlash This requires the setuptools_ package to be installed. If you have not done so already, download the `ez_setup.py`_ script and run it to install setuptools. Usage ----- Controller (``controllers.py``):: # Import TurboGears from turbogears import controllers, expose, redirect, validate, validators # Import fancyflash package import fancyflash as ff # Set the default timeout for message box display ff.set_default_flash_timeout(5) # Let FancyFlashWidget be included on every page ff.register_flash_widget() class FlashTestController(controllers.Controller): @expose('templates.welcome') def index(self, timeout=0): return {} @expose() def info(self): ff.info("Hello TurboGears!") redirect('/') @expose() @validate(validators=dict(timeout=validators.Int)) def success(self, timeout=0, tg_errors=None): ff.success("Hello TurboGears!", timeout) redirect('/') @expose() @validate(validators=dict(status=validators.String)) def message(self, status="info", tg_errors=None): ff.statusmessage("Hello TurboGears!", status) redirect('/') Master template (``master.kid``):: <div id="main_content"> <div py:replace="tg_fancyflashwidget(tg_flash)">Status message appears here</div> <div py:replace="[item.text]+item[:]"/> ... </div> Acknowledgments --------------- The idea for this widget is based on a `blog post`_ by Lee McFadden: .. _blog post: http://www.splee.co.uk/2005/11/23/fancy-status-messages-using-tg_flash/ Todo ---- * Test in IE * Test opacity in Safari If I have time: * Add argument for dialog position (implement by writing CSS dynamically). * Round boxes for non-Gecko browsers * Add AJAX widget, which displays result of ``loadJSONDoc`` as fancy status message. .. _api documentation: http://chrisarndt.de/projects/fancyflash/api/index.html .. _fancyflashexample: http://chrisarndt.de/projects/fancyflashexample/ .. _cheeseshop: http://cheeseshop.python.org/pypi/TurboFancyFlash .. _setuptools: http://peak.telecommunity.com/DevCenter/setuptools .. _easy_install: http://peak.telecommunity.com/DevCenter/EasyInstall .. _ez_setup.py: http://peak.telecommunity.com/dist/ez_setup.py TurboLucene 0.2.2 TurboLucene is a TurboGears extension that allows applications to easily use the PyLucene full-text search engine. Krys Wilken .. Revision: $Id: README 45 2007-04-01 21:09:24Z krys $ TurboLucene =========== About ----- TurboLucene is a library that allows TurboGears_ applications to use PyLucene_ for full text searching. It features a simple interface and takes care of all the nasty threading issues that exist between PyLucene and CherryPy_ (which is used by TurboGears). It now also features multi-lingual support for *Czech*, *Danish*, *German*, *Greek*, *English*, *Spanish*, *Finnish*, *French*, *Italian*, *Japanese*, *Korean*, *Dutch*, *Norwegian*, *Portuguese*, *Brazilian*, *Russian*, *Swedish*, and *Chinese*, including pre-configured stopwords for most languages. .. _TurboGears: http://turbogears.org/ .. _PyLucene: http://pylucene.osafoundation.org/ .. _CherryPy: http://cherrypy.org Requirements ------------ * PyLucene 2.0.0 or better * TurboGears 1.0 or better Thanks to setuptools, TurboGears and it's dependencies will be installed automatically, if necessary. However, PyLucene must be downloaded and installed manually. TurboLucene is not very demanding and may work with earlier versions of both PyLucene and TurboGears, but other versions have not been tested. Installation ------------ TurboLucene uses setuptools, so installation is as easy as:: easy_install TurboLucene or:: python setup.py install For more installation options, try:: python setup.py --help Manual Download --------------- The latest version can always be downloaded at http://dev.krys.ca/turbolucene. Documentation ------------- Documentation for TurboLucene can be found at: http://dev.krys.ca/turbolucene/#Documentation Limitations ----------- TurboLucene is still in early stages of development. It has not been optimised, extensively tested, benchmarked or profiled for performance or memory usage. Finally, there are no test cases yet. The plan is to eliminate these limitations, eventually. Patches and suggestions are welcome! :-) License ------- TurboLucene is licensed under the MIT license. See the LICENSE file for details. Contact ------- TurboLucene's web site is: http://dev.krys.ca/turbolucene You can find more documentation there. It is also where you can submit bugs. TurboLucene mailing list information can be found at: http://dev.krys.ca/turbolucene/#MailingList The mailing list is the place to ask any questions or make suggestions. Patches, bug reports, bug fixes and suggestions are all welcome! :-) Author ====== The author of TurboLucene is Krys Wilken. Feel free to contact him at krys AT krys DOT ca. Thanks ====== Special thanks goes out to all the brilliant and hard working people of the TurboGears and PyLucene projects. Without their tireless efforts, this project would not exist! Also thanks to everyone in the Open Source and Free Software communities. I really believe the spirit and philosophy of the FLOSS movement will change the world. I am happy to be able to give a little back. -
turbogears.command
Package Name Version Summary Author Description tgmigrate 0.2 sqlalchemy migrate command Fred Lin tgmigrate is an turbogears command extension which provide sqlalchemy migrate support. http://erosson.com/migrate/ The early version of tgmigrate gives turbogears developers a quick evaluation if sqlalchemy migrate is helpful for us. Install ---------------- easy_install tgmigrate Usage ---------------- After install, tgmigrate plug an "migrate" command into tg-admin console utility. The basic syntax is :: tg-admin migrate [command] tgmigrate takes care the dburi and repository name for you. The reference procedure is: 1. quickstart project as usual:: $ tg-admin quickstart -i -s demo 2. setup sqlalchemy dburi in demo/dev.cfg 3. create initial database $ tg-admin sql create 4. create repository "migration" $ tg-admin migrate create note the default repository folder named "migration" is created in your project folder. 5. move your database to version control $ tg-admin migrate version_control or briefly:: $ tg-admin migrate vc 6. Now you could watch the current version in both database and repository show repository version:: $ tg-admin migrate v (tg-admin migrate version) show database version:: $ tg-admin migrate dbv (tg-admin migrate db_version) then follow the migration doc http://erosson.com/migrate/docs/versioning.html to do the further stuff. Please post your comments or suggestions on TurboGears google group http://groups.google.com/group/turbogears reference -------------- You could use:: $ tg-admin migrate help to get all available commands and help The available commands are $ tg-admin migrate [command] command = [ 'help', 'create', 'script', 'commit', 'version', 'source', 'version_control', 'db_version', 'upgrade', 'downgrade', 'drop_version_control', 'manage', 'test'] tgcrud 1.0.2 Genrate CRUD interface in TurboGears Fred Lin tgcrud is an TurboGears command extension, which could generate a sqlobject/sqlalchemy backend editor/crud (create, read, update, delete) interface based on your Model with kid template. It could be plugged into any projects even if you don't use kid template. The generated codes are fully customizable. tgcrud heavily use form widgets and show you many TG 1.0 features in it's controllers/templates. Please refer to http://docs.turbogears.org/1.0/CRUDTemplate for detail The command follow the TurboGears quickstart template style, you could easily add identity, form validation, paginate in your crud interface. If you are a TG beginer, tgcrud help you create a general admin skeleton based on your model. If you are an experienced TG developer, you could get it in minutes since it just done the basic procedure that every time you write a management interface of your model. Features ---------------------- Fully customizable admin interface (the create, read, update, delete functions) with easy to extend(form validation, identity, paginate) templates. No Magic * The generated codes are normal TG source. * No extra magic encapsulation. No need to rewrite the interface when you need extra flexibility (not the same as Rails'scaffold) * Separate Form definition from Model (not the same as Django admin) * Use standard TurboGears syntax and code organization. * It's a good crud implementation reference by TG. TurboGears * Bundles a TurboGears "tg-admin crud" command. * Support SQLObject and SQLAlchemy models * tgcrud kid interface works for you no matter whatever template engine you currently choose for your project. * You could customize the model relationship by widgets(document shows how to customize 1-to-1, 1-to-many, many-to-many relationship with widgets. Or you could do it in your way) * Takes advantage of TurboGears form widgets and validation. you'd hardly need to modify the HTML. Install ---------- The 'tgcrud' command extension is available in Python CheeseShop and TurboGears svn. You can use setuptools to install tgcrud with following command:: $ easy_install tgcrud or download the source code and install tgcrud manually. Screencast -------------- Yes, there's a 'Make a Book Site with TurboGears' screencast with tgcrud. If you are an experienced TG developer, you could skip to the third. If you are new to TG, you may want to watch all of them to get familiar with TurboGears. - Quickstart TurboGears project, 6.5MB http://files.turbogears.org/video/openbook1.swf - Design model with toolbox utilities, 7.7MB http://files.turbogears.org/video/openbook2.swf - tgcrud, the TG's scaffold, 5.2 MB http://files.turbogears.org/video/openbook3.swf With tgcrud you could easily generate a Rails scaffold style CRUD interface. The difference is all code in tgcrud is implicit, which leads to more easy customization. Usage ---------- 1. Define your model in model.py 2. Once you've defined your model, you could use "tg-admin crud" command to generate the crud pack. The syntax is:: $ tg-admin crud [model class name] [package name] e.x if the model name is BookMark, and the package name we want is BookMarkController, the command is:: $ tg-admin crud BookMark BookMarkController Then the 'admin' package is generated. You just need take several minutes to customize the formfield to have a proper crud interface. ..note:: you could estimate the result by passing "--dry-run" to the command, such as:: $ tg-admin crud BookMark BookMarkController --dry-run With this argument the command will not effect your physical directories. 3. Import the package to your controllers.py with a line: from BookMarkController import BookMarkController and add a branch on your Root():: foo = BookMarkController() 4. Customize the form filed in admin/controllers.py 5. Open the http://localhost:8080/foo to use the customizable interface. Please check http://docs.turbogears.org/1.0/CRUDTemplate for detail instructions. ChangeLog ------------------------- 1.0.2 * Expand compatibility to all TurboGears 1 version 1.0.1 * Minor template updates 1.0 * Fully SQLAlchemy support with * SQLObject/SQLAlchemy auto detection * Able to specify the primary id * Minor template updates tg2exe 0.2 Make TurboGears project to the Stand Alone Windows Application Fred Lin tg2exe is a "tg-admin" command line utility extension which could help you converting the TurboGears project to an Stand Alone Application on windows platform. Advantage -------------- The benifit is you can use TurboGears' power to write Off-line applications with web interface and AJAX. When the application is running, your computer host as a web server (Actually it is). Your user can quickly evaluate your application without install python or related modules. Install -------------- You could use:: $ easy_install tg2exe command to install this module pywin32 is required http://sourceforge.net/projects/pywin32/ Usage ---------- Once you installed tg2exe, you'll got an 'makexe' command within the "tg-admin" command line utility. Enter your project folder, type:: tg-admin makexe and tg2exe will produce a dist folder for you. This utility does not make an *.exe, it assembles all the dependencies and runtime libraries into a single directory, so that it's easy to wrap everything into a single setup package. You are free to package 'dist' folder into an installer (such as InnoSetup). Notice that the stand alone file are equivalent to production project, so you need to have a setted prod.cfg. The simple approach is to rename the sample-prod.cfg to prod.cfg. Note ----------- The owe is its distribution size. The raw dist with quickstart project is about 12 MB. After a quick remove, 10MB is possible. Current Stage: make it work (next stages are make it better, then make it small) Credit ------------ tg2exe is based on the script written by Volodymyr Orlenko, he post the original script on TurboGears MailList in Jul 2006. If you have any question, please go to google turbogears group. History ------------ 0.1 2006/11/14 initial workable 0.2 2006/11/15 reduce 70% distribution size (30MB->12MB) -
turbogears.application
Package Name Version Summary Author Description -
turbogears
Package Name Version Summary Author Description webstring 0.5 Template engine that uses Python as the template language L. C. Rees *webstring* is a template engine for programmers whose favorite template language is Python. This release of *webstring* replaces the standalone packages *webstring*, *lwebstring*, TurboWebstring, and LturboWebstring. *webstring* supports: - plain text templating - advanced XML and HTML templating using *lxml* or cElementTree - templating with web frameworks that support the TurboGears template plugin API - WSGI templating middleware *webstring* is designed to: 1. Separate model and view logic from controller logic. 2. Separate template logic from template data. 3. Require only Python for templating. 4. Use Python syntax, idiom, and patterns. 5. Play well with other Python software. *webstring's* XML and HTML templating support is designed to: 1. Use XML as a data format, not a programming language. 2. Use existing XML formats. 3. Hide the parts of an XML document that are not being used. 4. Use the best Python XML processing libraries. 5. Bridge HTML and XML. TgRum 0.3.2dev-20090715 Some helpers to integrate Rum nicely into TurboGears Alberto Valverde Gonzalez, Michael Brickenstein UNKNOWN TurboZSI 0.5 TurboZSI A collection of tools for creating web services in the turbogears framework. Charles Moad A collection of tools for creating web services in the turbogears framework. tg.ext.silverplate 0.1rc3-r47 TurboGears Registration and Administration module Christopher Perkins UNKNOWN TurboLucene 0.2.2 TurboLucene is a TurboGears extension that allows applications to easily use the PyLucene full-text search engine. Krys Wilken .. Revision: $Id: README 45 2007-04-01 21:09:24Z krys $ TurboLucene =========== About ----- TurboLucene is a library that allows TurboGears_ applications to use PyLucene_ for full text searching. It features a simple interface and takes care of all the nasty threading issues that exist between PyLucene and CherryPy_ (which is used by TurboGears). It now also features multi-lingual support for *Czech*, *Danish*, *German*, *Greek*, *English*, *Spanish*, *Finnish*, *French*, *Italian*, *Japanese*, *Korean*, *Dutch*, *Norwegian*, *Portuguese*, *Brazilian*, *Russian*, *Swedish*, and *Chinese*, including pre-configured stopwords for most languages. .. _TurboGears: http://turbogears.org/ .. _PyLucene: http://pylucene.osafoundation.org/ .. _CherryPy: http://cherrypy.org Requirements ------------ * PyLucene 2.0.0 or better * TurboGears 1.0 or better Thanks to setuptools, TurboGears and it's dependencies will be installed automatically, if necessary. However, PyLucene must be downloaded and installed manually. TurboLucene is not very demanding and may work with earlier versions of both PyLucene and TurboGears, but other versions have not been tested. Installation ------------ TurboLucene uses setuptools, so installation is as easy as:: easy_install TurboLucene or:: python setup.py install For more installation options, try:: python setup.py --help Manual Download --------------- The latest version can always be downloaded at http://dev.krys.ca/turbolucene. Documentation ------------- Documentation for TurboLucene can be found at: http://dev.krys.ca/turbolucene/#Documentation Limitations ----------- TurboLucene is still in early stages of development. It has not been optimised, extensively tested, benchmarked or profiled for performance or memory usage. Finally, there are no test cases yet. The plan is to eliminate these limitations, eventually. Patches and suggestions are welcome! :-) License ------- TurboLucene is licensed under the MIT license. See the LICENSE file for details. Contact ------- TurboLucene's web site is: http://dev.krys.ca/turbolucene You can find more documentation there. It is also where you can submit bugs. TurboLucene mailing list information can be found at: http://dev.krys.ca/turbolucene/#MailingList The mailing list is the place to ask any questions or make suggestions. Patches, bug reports, bug fixes and suggestions are all welcome! :-) Author ====== The author of TurboLucene is Krys Wilken. Feel free to contact him at krys AT krys DOT ca. Thanks ====== Special thanks goes out to all the brilliant and hard working people of the TurboGears and PyLucene projects. Without their tireless efforts, this project would not exist! Also thanks to everyone in the Open Source and Free Software communities. I really believe the spirit and philosophy of the FLOSS movement will change the world. I am happy to be able to give a little back. TgRum 0.3.2dev-20100628 Some helpers to integrate Rum nicely into TurboGears Alberto Valverde Gonzalez, Michael Brickenstein UNKNOWN modwsgideploy 0.4.20dev Deploy Turbogears2 or Pylons via apache and modwsgi. Lukasz Szybalski Deployment using mod_wsgi and apache. Below instructions will tell you how to quickly deploy your turbogears2 app using mod_wsgi. Install modwsgideploy --------------------- PYPI ~~~~ You can install modwsgideploy from PyPi:: easy_install modwsgideploy Done. Source Install ~~~~~~~~~~~~~~ You also have a choice of getting the source and installing it. You should use this in a virtual environment, for example:: virtalenv --no-site-packages BASELINE source BASELINE/bin/activate Install [:Bazaar:] if its not already installed on your system:: easy_install bzr Branch out the code. This will pull all the revision history. If you want just the recent one use checkout:: bzr branch https://code.launchpad.net/~szybalski/modwsgideploy/trunk/ modwsgideploy_code Install it:: cd modwsgideploy_code/trunk python setup.py develop Run modwsgi_deploy ------------------ Go into your python application project folder and type in:: paster modwsgi_deploy Example ------- Here is a typical installation, from start to finish on Debian Linux. You might have to use you OS specific commands for installing apache. The steps are: 1) Install apache and modwsgi 2) Setup virtual environment and install tg2 3) Create tg2 app 'myapp' 4) Install modwsgideploy and tweak wsgi settings to fit your needs or use default settings. 5) Check if everything is running properly. In this case I will install apache using tools available from my Linux operating system:: aptitude install apache2 aptitude install libapache2-mod-wsgi virtualenv --no-site-packages BASELINE source BASELINE/bin/activate easy_install -i http://www.turbogears.org/2.0/downloads/current/index tg.devtools paster quickstart myapp Install modwsgideploy:: easy_install modwsgideploy Go into you app and run modwsgi_deploy command:: cd myapp paster modwsgi_deploy You should see an apache folder like this inside 'myapp':: myapp |-- apache | |-- README.txt | |-- myapp | |-- myapp.wsgi | `-- test.wsgi 1. Read the README.txt 2. myapp is a apache configuration file that you need to copy into your apache configuration folder after all the settings are set. 3. myapp.wsgi is an modwsgi script that is called from myapp apache file 4. test.wsgi is a test script that you can call to see if you modwsgi was properly installed and working. Edit myapp file to change any paths and/or apache configurations. Then copy to apache folder. On my operating system I copy this file to:: cp ./apache/myapp /etc/apache2/sites-available/ Enable the website. On my OS its:: a2ensite myapp /etc/init.d/apache restart Done Feedback -------- If you have a useful sample wsgi script or apache config that you would like to share, please sent it to Turbogears mailing list. repoze.what-pylons 1.0 The repoze.what v1 plugin for Pylons/TG2 integration Gustavo Narea ********************************************* The repoze.what plugin for Pylons integration ********************************************* This is an extras plugin for repoze.what which provides optional and handy utilities for Pylons applications using this authorization framework. Some of the features of the plugin include: * The utilities are ready to use: There's nothing additional to be configured before using. * 100% documented. Each component is documented along with code samples. * The test suite has a coverage of 100% and it will never decrease -- if it ever does, report it as a bug! * TurboGears 2 is officially supported as well. twFusionCharts 0.3dev Widgets for FusionChartsFree Tiago Cordeiro Marques Widgets for FusionChartsFree_ based on TGFusionCharts_ .. _TGFusionCharts: http://www.thesamet.com/TGFusionCharts/ .. _FusionChartsFree: http://www.fusioncharts.com/free/ ======== Install ======== easy_install twFusionCharts ==================================== Configuring ToscaWidgets with Pylons ==================================== See http://wiki.pylonshq.com/display/toscawidgets/Using+twForms+with+Pylons.+Part+1?showComments=false#id5 =========================== Usage Example with Pylons =========================== Controller:: from tw.fusioncharts import Column3DChartWidget, SingleSeriesChart def index(self): c.widget = Column3DChartWidget( chart_id='chart1', width=400, height=200, chart=SingleSeriesChart( [3,4,1,5], caption="New Incoming Links")) return render('/page.mako') Template (page.mako):: <html><head></head> ${h.literal(c.widget.render())} </html> wsgiview 0.2.1 Use TurboGears template plug-ins anywhere. L. C. Rees WSGI middleware that connects TurboGears/Buffet template plug-ins with any WSGI-enabled application. # Usage example: from wsgiview import view @view('webstring:template.html', format='html') def simple_app(environ, start_response): start_response('200 OK', [('Content-type','text/html')]) return {'test':'Hello world! '} if __name__ == '__main__': from wsgiref.simple_server import make_server http = make_server('', 8080, simple_app) http.serve_forever() -
tg2
Package Name Version Summary Author Description TGScheduler 1.6.1 Turbogears Scheduler Vince Spicer This scheduler that is based TG1's scheduler which was based on Kronos by Irmen de Jong. This scheduler makes it easy to have one time or recurring tasks run as needed tg.ext.repoze.who 0.1-r26 tg.ext.repoze.who are repoze.who plugins for TurboGears 2 Chris McDonough, Florent Aide, Christopher Perkins Sample repoze.who middleware config and plugins for TG2. This package depends on repoze.who 0.8 or better. Trying it Out - Install TG2 into a virtualenv. - Install this package into the same virtualenv via "setup.py install". - Create a TG2 quickstart project using the virtualenv's python. - In the development.ini of you project... - In the config.middleware module of your project, add the following just under "CUSTOM MIDDLEWARE HERE":: # CUSTOM MIDDLEWARE HERE (filtered by error handling middlewares) from tgrepozewho.middleware import make_who_middleware app = make_who_middleware(app, config, User, user_criterion, user_id_col, DBSession) - Add the following definitions in you model.__init__:: groups_table = Table('tg_group', metadata, Column('group_id', Integer, primary_key=True), Column('group_name', Unicode(16), unique=True), Column('display_name', Unicode(255)), Column('created', DateTime, default=datetime.datetime.now) ) users_table = Table('tg_user', metadata, Column('user_id', Integer, primary_key=True), Column('user_name', Unicode(16), unique=True), Column('email_address', Unicode(255), unique=True), Column('display_name', Unicode(255)), Column('password', Unicode(40)), Column('created', DateTime, default=datetime.datetime.now) ) permissions_table = Table('tg_permission', metadata, Column('permission_id', Integer, primary_key=True), Column('permission_name', Unicode(16), unique=True), Column('description', Unicode(255)) ) user_group_table = Table('tg_user_group', metadata, Column('user_id', Integer, ForeignKey('tg_user.user_id', onupdate="CASCADE", ondelete="CASCADE")), Column('group_id', Integer, ForeignKey('tg_group.group_id', onupdate="CASCADE", ondelete="CASCADE")) ) group_permission_table = Table('tg_group_permission', metadata, Column('group_id', Integer, ForeignKey('tg_group.group_id', onupdate="CASCADE", ondelete="CASCADE")), Column('permission_id', Integer, ForeignKey('tg_permission.permission_id', onupdate="CASCADE", ondelete="CASCADE")) ) # identity model class Group(object): """An ultra-simple group definition. """ def __repr__(self): return '<Group: name=%s>' % self.group_name class User(object): """Reasonably basic User definition. Probably would want additional attributes. """ def __repr__(self): return '<User: email="%s", display name="%s">' % ( self.email_address, self.display_name) def permissions(self): perms = set() for g in self.groups: perms = perms | set(g.permissions) return perms permissions = property(permissions) def by_email_address(klass, email): """A class method that can be used to search users based on their email addresses since it is unique. """ session = DBSession() return session.query(klass).filter(klass.email_address==email).first() by_email_address = classmethod(by_email_address) def by_user_name(klass, username): """A class method that permits to search users based on their user_name attribute. """ session = DBSession() return session.query(klass).filter(klass.user_name==username).first() by_user_name = classmethod(by_user_name) def _set_password(self, password): """encrypts password on the fly using the encryption algo defined in the configuration """ algorithm = config.get('authorize.hashmethod', None) self._password = self.__encrypt_password(algorithm, password) def _get_password(self): """returns password """ return self._password password = property(_get_password, _set_password) def __encrypt_password(self, algorithm, password): """Hash the given password with the specified algorithm. Valid values for algorithm are 'md5' and 'sha1'. All other algorithm values will be essentially a no-op.""" hashed_password = password if isinstance(password, unicode): password_8bit = password.encode('UTF-8') else: password_8bit = password if "md5" == algorithm: hashed_password = md5.new(password_8bit).hexdigest() elif "sha1" == algorithm: hashed_password = sha.new(password_8bit).hexdigest() # TODO: re-add the possibility to provide own hasing algo # here... just get the real config... #elif "custom" == algorithm: # custom_encryption_path = turbogears.config.get( # "identity.custom_encryption", None ) # # if custom_encryption_path: # custom_encryption = turbogears.util.load_class( # custom_encryption_path) # if custom_encryption: # hashed_password = custom_encryption(password_8bit) # make sure the hased password is an UTF-8 object at the end of the # process because SQLAlchemy _wants_ a unicode object for Unicode columns if not isinstance(hashed_password, unicode): hashed_password = hashed_password.decode('UTF-8') return hashed_password def validate_password(self, password): """Check the password against existing credentials. """ algorithm = config.get('authorize.hashmethod', None) return self.password == self.__encrypt_password(algorithm, password) class Permission(object): """A relationship that determines what each Group can do """ pass mapper(User, users_table, properties=dict(_password=users_table.c.password)) mapper(Group, groups_table, properties=dict(users=relation(User, secondary=user_group_table, backref='groups'))) mapper(Permission, permissions_table, properties=dict(groups=relation(Group, secondary=group_permission_table, backref='permissions'))) - Add the following import in you controllers.root file:: from tgrepozewho import authorize - Add the following methods to your controllers.root:RootController class:: @expose('whotg.templates.about') @authorize.require(authorize.has_permission('manage')) def manage_permission_only(self, **kw): return dict(now=now, page='about') @expose('whotg.templates.about') @authorize.require(authorize.is_user('editor')) def editor_user_only(self, **kw): return dict(now=now, page='about') @expose('whotg.templates.login') def login(self, **kw): came_from = kw.get('came_from', '/') return dict(now=now, page='login', header=lambda *arg: None, footer=lambda *arg: None, came_from=came_from) - Add the following template as "login.html" into your project's 'templates' directory:: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:py="http://genshi.edgewall.org/" xmlns:xi="http://www.w3.org/2001/XInclude"> <xi:include href="master.html" /> <head> <meta content="text/html; charset=UTF-8" http-equiv="content-type" py:replace="''"/> <title>Login Form</title> </head> <body> <form action="/login_handler?came_from=${came_from}" method="POST"> Login: <input type="text" name="login"></input><br/> Password: <input type="password" name="password"></input><br/> <input type="submit" name="submit"/> </form> </body> </html> - Setup you database config in the normal way by tweaking the development.ini file - Create the necessary tables by using:: paster setup-app development.ini - Create a user manually in your database - Create a group (any name), and a permission named "manage", link this permission to the group you just created and also add a user to your group. - Create another user which is in no group but is named "editor" - Start the project's server via paster serve:: paster server --reload development.ini - Visit http://localhost:8080/editor_user_only in your browser. You will be presented with the login form. The "right" username/password combination is "editor/editpass" (this user has the username 'editor'). Submitting this set of credentials will show the about page. Any other username/password combination will result in the user being presented the login form again. Note that once you've obtained the credentials for the first time, if you visit the /editor_user_only page again, you are not asked to reauthenticate. Log out forcibly by visiting http://localhost:8080/logout_handler. - Visit http://localhost:8080/manage_permission_only in your browser. You will be presented with the login form. The "right" username/password combination is "manager/managepass" (this user possesses the manage permission). Submitting this set of credentials will show the about page. Any other username/password combination will result in the user being presented the login form again. Note that if you've authenticated as the 'editor' user, and you visit the /manage_permission_only page, you will be logged out and asked for credentials (editors cannot see this page). Note that once you've obtained the credentials for the first time, if you visit the /manage_permission_only page again, you are not asked to reauthenticate. Log out forcibly by visiting http://localhost:8080/logout_handler. Misc If you start "paster serve" in a shell with the WHO_LOG environment variable set to "1", you will see repoze.who logging output on the console. Not yet finished You can run the unit tests by using "python setup.py test" in the source package. tgext.admin 0.3.10 Admin Controller add-on for basic TG identity model. Christopher Perkins Introduction ============ Changelog =========== 0.3 ---- Lookup now uses ProviderSelector, for better mongo support 0.2.6 ----- Bugfix release. Support for _method fields in TG2.1 0.2.5 ------ * Addition of defaultCrudRestController to CRCConfig allows one to customize the controller that the admin uses. * Fixes tgadminconfig to override the Password properly for Users Changelog ========= 0.1 - Unreleased ---------------- * Initial release libacr 0.52dev TurboGears2 Content Management Framework AXANT ACR is an open source Python content management system library for Turbogears It provides a set of tools to implement CMS functions inside any Turbogears2 application and comes with ACRCms which is a simple and free web content management system implemented with ACR as an example of how to use the library. ACR divides pages in Slices, which define what should be placed, where it should be placed and how it should be displayed Each Content can be used in more then one Slice and Slices can be rendered in both complete and preview mode. Using this interaction you can produce behaviours like having your blog post in its own page and a preview of it inside your main page, or have a photo/video and a preview of it inside your media gallery. ACR already supports previews of HTML documents, images and videos by generating thumbnails for the last two. ACR currently supports: * Multilanguage Content Support * Automatic translation using Google when translating content to a new language * Content versioning and revert * Image Galleries * Video Galleries * News/Blog? Sections * Users permissions * Autogenerated Vertical/Horizontal? Menus * Internal Search Engine * File Attachments * Remote Disk to upload and manage files * RSS Integration * Twitter Integration * Static and Dynamic Google Maps * Comments by users * Automatic Forms generation with email submission of data tgext.crud 0.3.8 Crud Controller Extension for TG2 Christopher Perkins Introduction ============ 0.3 (Sept. 30, 2009 ---------------------- * Mako template support * Title template fixes * Provider session bug fixed * TW 0.9.7.2 support * Pagination added. 0.2.x ------ Prehistory (should have kept better logs) Changelog ========= 0.1 - Unreleased ---------------- * Initial release -
repoze
Package Name Version Summary Author Description repoze.who-use_beaker 0.3 Identifier plugin for repoze.who with beaker.session cache implementation Linas Juškevičius What is repoze.who-use_beaker ============================= `repoze.who-use_beaker` is a repoze.who_ identifier_ plugin. It is aimed at replacing repoze.who.plugins.auth_tkt_ in order to store the user data in `beaker session`_. The plugin stores a dictionary containing at least `{'repoze.who.userid': userid}` under key `repoze.who.tkt`. ``UseBeakerPlugin`` takes the following parameters: - `key_name` (default: `repoze.who.tkt`) - the key name to store the userid under:: >>> userid = session['repoze.who.tkt'] - `session_name` (default: `beaker.session`) - the key name of the beaker session in the WSGI environment:: >>> session = environ['beaker.session'] - `delete_on_logout` (default: `false`) - if `false` then on logout ``session['repoze.who.tkt']`` is erased but the other session data stays and will be reused during the next session. If you want the session to be invalidated pass ``delete_on_logout = True`` - `alsopersist` (default: `['userdata']`) - a sequence of item keys that are persisted along to `repoze.who.userid` Usually you should use `make_plugin` method instead of instantiating `UseBeakerPlugin` directly:: >>> from repoze.who.plugins.use_beaker import make_plugin >>> plugin = make_plugin(**kw) In order to properly use the `beaker.session` `repoze.who` (with `repoze.who-use_beaker`) has to be placed lower in the WSGI stack. Usually this means that you have to define `repoze.who` in your framework's middleware configuration higher than beaker session. E.g. (using the factory from repoze.what-quickstart_):: >>> from beaker.middleware import SessionMiddleware >>> from repoze.what.plugins.quickstart import setup_sql_auth >>> from repoze.who.plugins.use_beaker import make_plugin as make_beaker_plugin ... # app definition here >>> app = setup_sql_auth(app, ... User, Group, Permission, DBSession, ... # HERE we provide the beaker plugin to be used as the primary identifier ... identifiers=[('use_beaker', make_beaker_plugin())], ... form_plugin=... # The rest of repoze configuration ... # more middlewares here >>> app = SessionMiddleware(app, config) Git repository is located at GitHub.com_. .. _repoze.who: http://docs.repoze.org/who .. _identifier: http://docs.repoze.org/who/narr.html#identifier-plugins .. _beaker session: http://beaker.groovie.org/sessions.html .. _repoze.who.plugins.auth_tkt: http://docs.repoze.org/who/narr.html#repoze.who.plugins.auth_tkt.AuthTktCookiePlugin .. _repoze.what-quickstart: http://code.gustavonarea.net/repoze.what-quickstart .. _GitHub.com: http://github.com/kaukas/repoze.who-use_beaker repoze.who.plugins.openid 0.5.2 An OpenID plugin for repoze.who Christian Scholz Introduction ============ ``repoze.who.plugins.openid`` is a plugin for the `repoze.who framework <http://static.repoze.org/whodocs/>`_ enabling `OpenID <http://openid.net>`_ logins. For more information read the `documentation <http://quantumcore.org/docs/repoze.who.plugins.openid>`_ or check out the `source code <http://code.google.com/p/repozeopenid/>`_. Changelog ========= 0.5.2 - September 25th 2009 --------------------------- * added MANIFEST.in to make egg work again 0.5.1 - September 25th 2009 --------------------------- * fixed setup.py (removed doubles test suite) 0.5 - March 15th 2009 --------------------- * Initial release afpy.ldap 0.8.2 This module provide an easy way to deal with ldap stuff in python. Gael Pasgrimaud afpy.ldap ========= This module is actively used on http://www.afpy.org to manage the french python comunity members. The following examples show all features of the package. If you just want to give it a try in a quickest way read `Installation and configuration <http://hg.afpy.org/gawel/afpy.ldap/install.html>`_ from the Sphinx documentation. Get a connection (this custom afpy connection get is configuration from a `~/.ldap.ini` file. See `Installation and configuration <http://hg.afpy.org/gawel/afpy.ldap/install.html>`_):: >>> from afpy.ldap import custom as ldap >>> conn = ldap.get_conn() Get a node via is dn:: >>> dn = 'uid=gawel,ou=members,dc=afpy,dc=org' >>> node = conn.get_node(dn) >>> node <Node at uid=gawel,ou=members,dc=afpy,dc=org> >>> print node.birthDate 19750410000000Z You can also define your own node class with a schema:: >>> from afpy.ldap.node import Node >>> from afpy.ldap import schema >>> class User(Node): ... uid=schema.StringProperty('uid') ... birthDate = schema.DateProperty('birthDate', title='Date de naissance') >>> node = conn.get_node(dn, node_class=User) >>> node <User at uid=gawel,ou=members,dc=afpy,dc=org> Then data is converted to a python object:: >>> node.birthDate datetime.date(1975, 4, 10) This also allow to generate forms with FormAlchemy_:: >>> from afpy.ldap import forms >>> fs = forms.FieldSet(User) >>> user = User() >>> fs.rebind(user) >>> print fs.render().strip() # doctest: +ELLIPSIS +NORMALIZE_WHITESPACE <div> <label class="field_opt" for="User--uid">Uid</label> <input id="User--uid" name="User--uid" type="text" /> </div> ... <div> <label class="field_opt" for="User--birthDate">Date de naissance</label> ... .. _FormAlchemy: http://docs.formalchemy.org The source code can be find on the `AFPy repository`_ .. _AFPy repository: http://hg.afpy.org/gawel/afpy.ldap/summary Got a bug, feature request ? Want to send beer because you love it ? Send an email at gawel@afpy.org or join us on the #afpy channel on freenode. News ===== 0.8.2 ------ - Add ListOfGroups and ListOfPerms attributes. Allow to set user.groups = [] 0.8.1 ----- - fix authentification failure when uid does not exist 0.8 --- - small fixes - add GroupOfUniqueNames 0.7 --- - Add repoze.what plugins - Allow to set node classes via config file - fix compat with latest python-ldap 0.5 ----- - require dataflake.ldapconnection>=1.0b1, python-ldap>=2.3.10 0.1 ----- - initial version repoze.who.plugins.cas 0.1.1 CAS plugin for repoze.who by Makina Corpus Simon Thepot, Mathieu Pasquet Introduction ============ ``repoze.who.plugins.cas`` is a plugin for the `repoze.who framework <http://static.repoze.org/whodocs/>`_ enabling straightforward "cassification" (i.e.: makings each of your applications part of the SSO mecanism) of all applications that can be deployed through `Python Paste <http://pythonpaste.org/deploy/>`_. It currently supports CAS 3.0, although it mays be used with others versions of CAS (yet, no compatiblity is ensured as it has only been tested with CAS 3.0). Applications which can be used : - App complying with the `simple_authentication WSGI specification <http://wsgi.org/wsgi/Specifications/simple_authentication>`_, which take advantage of the REMOTE_USER key in the WSGI environment. - App which can handle themselves the CAS mecanism (e.g.: phpBB with the CAS patch, - use wphp as a paste filter for integration of PHP with python - ) Links : - `Official link for CAS <http://www.jasig.org/cas>`_ .. contents:: Credits ====================================== |makinacom|_ * `Planet Makina Corpus <http://www.makina-corpus.org>`_ * `Contact us <mailto:python@makina-corpus.org>`_ .. |makinacom| image:: http://depot.makina-corpus.org/public/logo.gif .. _makinacom: http://www.makina-corpus.com Installing ========== Requirement ++++++++++++ You must have a CAS server working. CAS +++ You must also have enabled the logout which basically is adding ``<property name="followServiceRedirects" value="true" />`` in the LogoutController bean in the cas-servlet.xml. Your apps +++++++++ Nothing is required for your apps, just set them up and fill out the config file as seen in the demo/ directory. The configuration is pretty straightforward, you should take example on the config files demo provided with the egg. Here is what you can find in it, for the who.ini file:: # IDENTIFIER # @param : # - rememberer_name : name of the plugin for remembering (delegate) # - path_toskip : regex for url handling their own way the CAS authent # - path_logout : regex to see if a logout has to be performed (and trigger forget via challenge) # WARNING : must include the path of logout even for path_toskip application # to properly logging out from the CAS also [plugin:casauth] use = repoze.who.plugins.cas.main_plugin:make_plugin cas_url= https://servcas:8443/cas/ rememberer_name = auth_tkt path_toskip = .*/phpbb/.* path_logout = .*/logout.* .*mode=logout.* # CHALLENGE DECIDER # @param: # - path_login : those regexp indicate which url should be redirected for a challenge # e.g. : for CAS, will be redirected on a "/cas/login" like url [plugin:decider] use = repoze.who.plugins.cas.challenge_decider:make_plugin path_login = .*trac/login.* .*/login$ [plugin:auth_tkt] # identification use = repoze.who.plugins.auth_tkt:make_plugin secret = secret cookie_name = oatmeal secure = False include_ip = False [general] request_classifier = repoze.who.classifiers:default_request_classifier remote_user_key = REMOTE_USER # trick : target the plugin whose name is the same challenge_decider = decider [identifiers] # plugin_name;classifier_name:.. or just plugin_name (good for any) plugins = casauth [authenticators] # plugin_name;classifier_name.. or just plugin_name (good for any) plugins = casauth [challengers] # plugin_name;classifier_name:.. or just plugin_name (good for any) plugins = casauth TODO: improvement for the future ================================ More Tests ++++++++++ Some scenarios deploying severals applications and running doctests on it will be soon available. Handling Single Sign Out ++++++++++++++++++++++++ At this point, this plugin does handle SSO (Single Sign On). Yet, it does not handle Single Sign Out. There may be several ways to achieve this. - A simple solution may be found by enabling the plugin to execute each callable delivered by webapp whose purpose would be to logout the user from it (e.g: by redirecting the browser on the logout url, or deleting some cookies etc.). - Currently, CAS 3 and higher handle SSOut by triggering a POST request to all the web application registered. I did not digg this option at all, wonder how it would fit or not. - ... Not relying on the CAS server itself ? ++++++++++++++++++++++++++++++++++++++ At the moment, the plugin relies on a CAS server. Yet, CAS is just a specific trusted third party (e.g.: like Kerberos etc.) Thus, to avoid code redundancy between plugins dealing with concrete implementation of this "trusted third party abstraction", we should code against this abstraction => refactor this code. Yet, of course, rather than extending this plugin, we may create a new one, if each implementations tends to get very specific. Misc ++++ Clearing and make more relevant comments ;) KNOWN ISSUES ============ Changes ======= 0.1 (2009-07-28) ++++++++++++++++ Initial release. - Provides repoze.who plugins (i.e.: challenge, identifier, chalenge decider and auth plugins) for enabling CAS - Provides simple unit tests repoze.who.plugins.sa 1.0rc2 The repoze.who SQLAlchemy plugin Gustavo Narea ******************************** The repoze.who SQLAlchemy plugin ******************************** This plugin provides one repoze.who authenticator and one metadata provider which works with SQLAlchemy or Elixir-based models. repoze.tm2 1.0a5 Zope-like transaction manager via WSGI middleware Agendaless Consulting repoze.tm2 (Transaction Manager) ================================ Middleware which uses the ZODB transaction manager to wrap a call to its pipeline children inside a transaction. This is a fork of the ``repoze.tm`` package which depends only on the ``transaction`` package rather than the entirety of ZODB (for users who don't rely on ZODB). See docs/index.rst for documentation. 1.0a5 (2009/9/7) ================ - Don't commit after aborting if the transaction was doomed or if the commit veto aborted. - Don't use "real" transaction module in tests. - 100% test coverage. 1.0a4 (2009/1/6) ================ - RESTify CHANGES, move docs in README.txt into Sphinx. - Remove ``setup.cfg`` (all dependencies available via PyPI). - Synchronization point with ``repoze.tm`` (0.9). 1.0a3 ===== Allow ``commit_veto`` hook to be specified within Paste config, ala:: [filter:tm] use = repoze.tm:make_tm commit_veto = some.package:myfunction ``myfunction`` should take three args: environ, status, headers and should return True if the txn should be aborted, False if it should be committed. Initial PyPI release. 1.0a2 (2008/7/15) ================= - Provide "commit_veto" hook point (contributed by Alberto Valverde). - Point easy_install at http://dist.repoze.org/tm2/dev/simple via setup.cfg. 1.0a1 ===== - Fork point: we've created repoze.tm2, which is repoze.tm that has a dependency only on the 'transaction' package instead of all of ZODB. - Better documentation for non-Zope usage in README.txt. 0.8 === - Relaxed requirement for ZODB 3.7.2, since we might need to use the package with other verions. Note that the tests which depend on transaction having "doom" semantics don't work with 3.7.2, anyway. 0.7 === - Depend on PyPI release of ZODB 3.7.2. Upgrade to this by doing bin/easy_install -U 'ZODB3 >= 3.7.1, < 3.8.0a' if necessary. 0.6 === - after_end.register and after_end.unregister must now be passed a transaction object rather than a WSGI environment to avoid the possibility that the WSGI environment used by a child participating in transaction management won't be the same one used by the repoze.tm package. - repoze.tm now inserts a key into the WSGI environment (``repoze.tm.active``) if it's active in the WSGI pipeline. An API function, repoze.tm:isActive can be called with a single argument, the WSGI environment, to check if the middleware is active. 0.5 === - Depend on rerolled ZODB 3.7.1 instead of zopelib. - Add license and copyright, change trove classifiers. 0.4 === - Depend on zopelib rather than ZODB 3.8.0b3 distribution, because the ZODB distribution pulls in various packages (zope.interface and ZEO most notably) that are incompatible with stock Zope 2.10.4 apps and older sandboxes. We'll need to revisit this. 0.3 === - Provide limited compatibility for older transaction package versions which don't support the 'transaction.isDoomed' API. 0.2 === - Provide after_end API for registering callbacks at transaction end. 0.1 === - Initial Release repoze.lru 0.3 A tiny LRU cache implementation and decorator Agendaless Consulting repoze.lru ========== ``repoze.lru`` is a LRU (least recently used) cache implementation. Keys and values that are not used frequently will be evicted from the cache faster than keys and values that are used frequently. API --- Creating an LRUCache object:: from repoze.lru import LRUCache cache = LRUCache(100) # 100 max length Retrieving from an LRUCache object:: cache.get('nonexisting', 'foo') # will return 'foo' cache.get('nonexisting') # will return None cache.get('existing') # will return the value for existing Adding to an LRUCache object:: cache.put('key', 'value') # will add the key 'key' with the value 'value' Clearing an LRUCache:: cache.clear() Decorator --------- A ``lru_cache`` decorator exists. All values passed to the decorated function must be hashable. It does not support keyword arguments:: from repoze.lru import lru_cache @lru_cache(500) def expensive_function(*arg): pass Each function decorated with the lru_cache decorator uses its own cache related to that function. repoze.lru ========== 0.3 (2009/06/16) ---------------- - Add a thread lock around ``clear`` logic. 0.2 (2009/06/15) ---------------- - Add a ``clear`` method. 0.1 (2009/06/14) ---------------- - Initial release. repoze.vhm 0.13 repoze virtual hosting middleware. Agendaless Consulting repoze.vhm README ================= .. contents:: Overview -------- This package provides middleware and utilities for doing virtual hosting within a WSGI/Repoze environment. It is particularly useful within a ``repoze.zope2`` environment, where it may be used as an alternative to the classic `VirtualHostMonster <http://www.zope.org/Members/4am/SiteAccess2/info>`_: method of doing virtual hosting. Virtual Hosting in a Nutshell ----------------------------- "Virtual hosting" enables dynamic applications to be served from within a larger URL namespace, independent of the physical location of the script files used to serve the application, or the precise layout of objects within the application. In particular, the application and the server collaborate to generate URLs for links in the application, such that the links preserve the "apparent" location of the application. The simplest case requires no effort at all: links rendered as relative paths from within pages work nicely. However, such links begin to be problematic quickly, e.g. when the page is serving as the default index view for its folder, and the URL does not end in a ``/``. In that case, the browser interprets the links relative to the folder's parent, and chaos ensues. CGI Environment Variables ------------------------- As used for applications running "inside" Apache (e.g., using ``mod_python``), there follwing environment variables are of interest when doing virtual hosting: SERVER_NAME the name which the server believes it has. HTTP_HOST the apparent hostname of the server (i.e., as passed in the ``Host:`` header) SERVER_PORT the apparent port of the server SCRIPT_NAME any path prefix used by Apache to dispatch to the application (as defined via the ``ScriptAlias`` directive). PATH_INFO the remainder of the path, after removing any parts used in dispatch. ``repoze.vhm#vhm_xheaders`` WSGI Filter --------------------------------------- When configured as WSGI middleware, this filter will convert the path information in the environment from the "X-Vhm" headers added to the request into the "standard" CGI environment variables outlined above. It will also place repoze.vhm-specific environment variables into the WSGI environment for consumption by repoze.zope2 (or another application which chooses to use its services). If this filter is placed into the pipeline in front of a Zope 2 application, the standard Virtual Host Monster object (``/virtual_hosting``) may be deleted, as it is no longer necessary. However, it does not need to be deleted; repoze.vhm will work if it is present. The filter requires no configuration; it can be added to any pipeline via its egg name: ``egg:repoze.vhm#vhm_xheaders``. ``repoze.vhm#vhm_explicit`` WSGI Filter --------------------------------------- This filter is like the repoze.vhm#vhm_xheaders filter, but instead of taking the virtual host and/or root from the environment, they are explicitly configured when the middleware is instantiated. If using paste.deploy, this looks like:: [filter:vhm] use = egg:repoze.vhm#vhm_explicit host = http://www.example.com root = /mysite Both 'host' and 'root' are optional, but you probably want to specify at least one of them. ``repoze.vhm#vhm_path`` WSGI Filter ------------------------------------- As a fallback for proxies which cannot add headers to proxied requests, this filter implements the same path-based virtual hosting syntax used by the Zope2 Virtual Host Monster. Because this syntax is quite arcane (so much that there is a web-app for generating the rewrite rules!), this filter is not recommended except for environments which cannot be configured to add headers (e.g., Apache has ``mod_rewrite`` enabled, but cannot be changed to enable ``mod_headers``). When configured as WSGI middleware, this filter will convert the path information in the environment from the classic "Zope2 virtual hosting mungned URL" into the "standard" CGI environment variables outlined above. It will also place repoze.vhm-specific environment variables into the WSGI environment for consumption by repoze.zope2 (or another application which chooses to use its services). If this filter is placed into the pipeline in front of a Zope 2 application, the standard Virtual Host Monster object (``/virtual_hosting``) may be deleted, as it is no longer necessary. However, it does not need to be deleted; repoze.vhm will work if it is present. The filter requires no configuration; it can be added to any pipeline via its egg name: ``egg:repoze.vhm#vhm_path``. You can set the ``conserve_path_infos`` parameter if you want only the host and port bits to be touched.:: [filter:vhm] use = egg:repoze.vhm#vhm_path conserve_path_infos = true This trick can be useful to forward the url AS-IS to an underlying equipment wiwhtout touching to the URI. Eg, a wsgi pipeline where our repoze.vhm filters some content from a stock zope2 server which do the VHM stuff also on its own. Example: a deliverance middleware filtering out a stock zope2+plone server ----------------------------------------------------------------------------- We have in this setup a frontal apache server reverse proxyfing a deliverance server. First, we will tell apache to proxy our requests to our backends. Apache will tell: - At the wsgi level, rewrite links using things in the request headers - At the zope2 level, use the URL with vhmonster to rewrite links. :: # Rewrite links in paste RequestHeader add X-Vhm-Host http://host.tld:80/ # /_themes & .deliverance -> deliverance ProxyPassMatch /(_themes|\.deliverance)(.*) http://localhost:8378/$1$2 ProxyPassReverse /_themes/ http://localhost:8378/_themes/ ProxyPassReverse /.deliverance/ http://localhost:8378/.deliverance/ # application mounted on / does not needs _vh_ # /zmiroot -> access to zmi ProxyPassMatch ^/zmiroot(.*) http://localhost:8381/VirtualHostBase/http/host.tld:80/VirtualHostRoot/_vh_zmiroot$1 ProxyPassReverse ^/zmiroot/ http://localhost:8381/VirtualHostBase/http/host.tld:80/VirtualHostRoot/_vh_zmiroot/ # /plone-plonesiteid-> vhmonster without deliverance filtering ProxyPassMatch ^/plone-plonesiteid(.*) http://localhost:8381/VirtualHostBase/http/host.tld:80/plonesiteid/VirtualHostRoot/_vh_plone-plonesiteid$1 ProxyPassReverse ^/plone-plonesiteid/ http://localhost:8381/VirtualHostBase/http/host.tld:80/plonesiteid/VirtualHostRoot/_vh_plone-plonesiteid/ # /-> zope2vhmonster ProxyPass / http://localhost:8378/VirtualHostBase/http/host.tld:80/plonesiteid/VirtualHostRoot/ ProxyPassReverse / http://localhost:8378/VirtualHostBase/http/host.tld:80/plonesiteid/VirtualHostRoot/ This deliverance server is just another PasteDeploy setup which query somehow a zope2 server listening somewhere. :: [DEFAULT] debug=false [app:athemes] use = egg:Paste#static document_root=%(here)s/sometheme/path [app:azopeproxy] use = egg:Paste#proxy address=http://ZOPE:8381/ [filter:fdeliverance] use=egg:Deliverance theme_uri = sometheme rule_uri = file://somerules execute_pyref=true [filter:ftranslogger] use=egg:Paste#translogger setup_console_handler=true [filter:fexc] use=egg:WebError#evalerror [filter:fvhm] use = egg:repoze.vhm#vhm_xheaders [pipeline:pmain] pipeline = fexc ftranslogger fvhm fdeliverance azopeproxy [composite:main] use = egg:Paste#urlmap / = pmain /_themes = athemes [server:main] use=egg:Paste#http host = localhost port = 8378 repoze.vhm Virtual Hosting Model -------------------------------- This model (based on a `suggestion of Ian Bicking's , <http://blog.ianbicking.org/2007/08/10/defaults-inheritance/>`_), passes virtual hosting information from the proxy / web server to the application by adding extra headers to the proxied request: HTTP_X_VHM_HOST indicates the apparent URL prefix of the root of the application (concatenating ``wsgi.url_scheme``, ``SERVER_NAME``, ``SERVER_PORT``, and ``SCRIPT_NAME`` variables; the equivalent of Zope2's ``SERVER_URL``). HTTP_X_VHM_ROOT path of the object within the application which is supposed to function as the "virtual root". When serving an application from "within" Apache via mod_wsgi, we can just set the environment directly:: <Directory /path/to/wsgiapp> SetEnv HTTP_X_VHM_HOST http://www.example.com SetEnv HTTP_X_VHM_ROOT /cms </Directory> If you are serving repoze.zope2 via a proxy rewrite rule, you may pass this information by adding additional headers. E.g., a sample Apache configuration for the example above might be:: <VirtualHost *:80> ServerName www.example.com RewriteEngine on RewriteRule ^/(.*) http://localhost:8080/$1 [P,L] RequestHeader add X-Vhm-Host http://www.example.com RequestHeader add X-Vhm-Root /cms </VirtualHost> In either of the above example cases, the effect on repoze.zope2 when repoze.vhm's filter is in the WSGI pipeline is the same: the apparent root of ``http://www.example.com`` will be the default view of the object that has a physical path of ``/cms``. Additionally, paths in URLs generated by Zope will not start with ``/cms``, and the scheme and hostname in URLs will be "http://www.example.com" as opposed to ``http://localhost:8080``. The "vhm host" header may contain further path information as necessary; further path information can (and will, in the case of repoze.zope2) be respected by downstream applications to root an application at a non-server-root path :: <Directory /path/to/wsgiapp> SetEnv HTTP_X_VHM_HOST http://www.example.com/further/path SetEnv HTTP_X_VHM_ROOT /cms </Directory> In this case, URLs generated by Zope will begin with ``http://www.example.com/further/path``. This syntax replaces the "inside out" virtual hosting syntax (``_vh_`` segment markers in the URL) as described in the "Virtual Host Monster" documentation. The "vhm host" and "vhm root" headers can be used independently (the system will operate as you would expect in the absence of one or the other). ``repoze.vhm`` Library API -------------------------- Because the existing Zope 2 virtual hosting machinery does not rely on the "standard" CGI variables, the application dispatcher needs to "fix up" the environment to match Zope's expectations. ``repoze.vhm`` offers the following functions to aid in this fixup: repoze.vhm.utils.setServerURL convert the standard CGI virtual hosting environment into the form expected by Zope2 (adding the ``SERVER_URL`` key). repoze.vhm.utils.getVirtualRoot return the virtual root path (``repoze.vhm.virtual_root``) as set by the middleware. repoze.vhm Changelog ==================== 0.13 (2010-04-18) ----------------- - add conserve_path_infos for the VHMPathFilter middleware [kiorky] 0.12 (2010-01-01) ----------------- - Update tests of middleware to check only that ``munge`` is called correctly. - Test ``munge`` sepearately. - 100% test coverage. - fixed xheaders filter to set PATH_INFO correctly [vangheem] 0.11 (2009-08-31) ----------------- - Add a repoze.vhm#vhm_explicit filter. This is like the vhm_xheaders middleware, but the VHM host and/or root are set in the WSGI configuration instead of in the request. - Calculate a VIRTUAL_URL and put it into the environment. This is basically the URL that the end user sees. repoze.zope2 >= 1.0.2 uses this to compute the ACTUAL_URL request variable, for example. 0.10 (2009-08-26) ----------------- - Apply the HTTP_HOST port number fix to the VHM Path filter as well. 0.9 (2009-07-09) ---------------- - 100% test coverage. - ``HTTP_HOST`` parameter now includes port number if not http:80 or https:443. Thanks to Martin Aspeli. 0.8 (2009-01-10) ---------------- - Set 'HTTP_HOST' in environ to the same value as 'SERVER_NAME', FBO apps which need it. 0.7 (2008-05-07) ---------------- - Remove 'dependency-links=' to dist.repoze.org to prevent easy_install from searching there inappropriately. 0.6 (2008-04-17) ---------------- - Re-added the path-segment-based filter as an option, to support scenarios in which the reverse proxy can be configured to rewrite the URL but not to add headers. 0.5 (2008-03-09) ---------------- - Brown bag release: I fudged the entry point for the xheaders filter. 0.4 (2008-03-09) ---------------- - Kill off path-segment-based filter (repoze.vhm.zope2). Only the xheaders filter remains. - Add license headers. - The middleware now sets a 'repoze.vhm.virtual_host_base' which is preferred by setServerUrl over 'HTTP_HOST' when present. - Add a getVirtualRoot API. 0.3 (2007-10-25) ---------------- - Fix setServerURL method to take into account HTTP_HOST passed by client. 0.2 (2007-09-22) ---------------- - Change repoze.vhm.zope2:setServerURL to allow Zope 2 to generate the correct request['URL'] value when the vhm is in the pipeline. 0.1 (2007-09-21) ---------------- - Initial release. repoze.workflow 0.5 Content workflow for repoze.bfg Agendaless Consulting repoze.workflow =============== repoze.workflow is a state machine and associated configuration system useful for workflow-like applications. Refer to docs/index.rst or `the online docs <http://docs.repoze.org/workflow>`_ for further information. repoze.workflow Changelog ========================= 0.5 (2009-08-27) ---------------- - Major overhaul. Older "statemachine" workflows still work, but are deprecated. Workflow declarations may now be performed via ZCML. Documentation overhauled to reflect this fact. 0.4 (2009-06-24) ---------------- - 100% test coverage. - Allow ``add`` method to accept arbitrary keyword arguments. These keyword arguments are now passed as ``**kw`` to transition functions as well as ``before_transition`` and ``after_transition``. This allows arbitrary metadata (such as security and UI information) to be associated with a transition. - The ``transitions`` method now returns all transitions, including "catch-all" transitions (transitions with a transition_id of None). - Add ``transition_info`` method to state machine, which 0.3 (2009-04-10) ---------------- - Removed mutable default arguments, to avoid polluting one state machine's states when adding to another. 0.2 (2009-02-20) ---------------- - Initial release. Updated README.txt and removed remnants from repoze package template. 0.1 --- - Unreleased repoze.mailin 0.3.1 Map inbound mail onto application-defined handlers Agendaless Consulting repoze.mailin README ==================== This package provides a framework for mapping inbound e-mail onto application-defined handlers. Please see docs/index.rst for the documentation. repoze.mailin Changelog ======================= 0.3.1 (2009-07-08) ------------------ - N.B.: the quarantine feature introduced in version 0.3 requires a backward-incompatible change to the database scehma. Existing databases will not have the extra columns required to support the new feature. The simplest fix is as follows: * Stop any ongoing processing using the pending database. * Dump any existing message IDs from the database. * Move aside the database file. * Rerun the script which creates the database file. * Restore any dumped message IDs. 0.3 (2009-07-08) ---------------- - Added quarantine to pending queue. 0.2 (2009-06-23) ---------------- - 100% unit test coverage. - Hardened ``PendingQueue.pop`` against RFC-violating message IDs with non-decodable 8-bit characters. - Added logging of underflows in ``PendingQueue.pop``. - Made ``PendingQueue.pop`` a normal method, rather than a generator. - Added ``PendingQueue.logger`` attribute: if set, should obey the interface of a ``logging`` module logger. 0.1.5 (2009-05-31) ------------------ - Skip incoming messages with duplicate message ids to messages we have already processed; apparently some Microsoft clients resend messages without updating the Message-Id header, in violation of RFCs. 0.1.4 (2009-05-04) ------------------ - Fixed case where pop with multiple pending IDs and a given isolation level would cause the delete to fail with 'database locked'. See: https://bugs.launchpad.net/karl3/+bug/364251 - Fixed bug found by inspection where "underflow" on pop would leave the message IDs which *had* been returned on the queue. 0.1.3 (2009-03-13) ------------------ - Added ``PendingQueue.__del__`` to ensure closing the SQL connection. - ``MaildirStore.drainInbox``: don't remove the message from the maildir until after adding to the store. 0.1.2 (2009-01-22) ------------------ - Made ``draino`` script explicitly commit sqlite transactions if not running in ``dry-run`` mode. - Added ``isolation_level`` argument to ``MaildirStore.__init__``, to allow control of how the queue commits transactions. The default, ``None``, causes the connection to defer commits. 0.1.1 (2009-01-16) ------------------ - Added ``isolation_level`` argument to ``PendingQueue.__init__``, to allow control of how the queue commits transactions. The default, ``None``, causes the connection to autocommit after each statement. 0.1 (2009-01-15) ---------------- - Initial release. BlastOff 0.2 A Pylons application template providing a working site skeleton configured with SQLAlchemy, mako, repoze.who, ToscaWidgets, TurboMail, WebFlash and (optionally) SchemaBot. The generated app is pre-configured with authentication, login and registration forms, and (optionally) email confirmation. Chris Miles BlastOff helps accelerate Pylons application development by generating a project with a number of pre-configured dependencies. Installation ------------ Use pip:: $ pip install BlastOff or use setuptools:: $ easy_install BlastOff or old school, download the package from http://pypi.python.org/pypi/BlastOff, unpack it and run (as root if required):: $ python setup.py install Usage ----- Create a new Pylons project from the BlastOff template with:: $ paster create -t blastoff AppName You will be prompted for a few options. 1. SQLAlchemy database URL:: Enter sqlalchemy_url (The SQLAlchemy URL of the database) ['sqlite:///%(here)s/development.db']: Specify the database URL that will be used by SQLAlchemy. Defaults to an SQLite database. For PostgreSQL use something like:: postgres://user:pass@hostname/dbname 2. SchemaBot database schema version control:: Enter use_schemabot (Enable database schema version control using SchemaBot) [True]: If True then SchemaBot will be used to automatically manage the SQLAlchemy database schema. 3. Email confirmation to activate new user accounts:: Enter email_confirmation (True/False: New users must click activation link from confirmation email) [True]: If True the application will be configured to send a confirmation email to the user upon registration. The email will contain a link for activating the account before it can be used. If False no activation confirmation will be configured so users will be able to login immediately after registering. 4. Create a default user:: Enter default_user (Default username to create, password will match username (leave blank for no default user)) ['']: To have a default user created when the database is set up enter the username here. After creation the Pylons app is ready to be used. To ensure all the application dependencies are installed you can run this command from the application directory:: $ python setup.py develop Before starting the app the database needs to be set up (i.e. tables created). This is done by using the standard Pylons command:: $ paster setup-app development.ini If the SchemaBot option was enabled then a BlastOff generated project will use SchemaBot to manage database schema changes. The initial tables will be created by SchemaBot, the default user inserted if that option was selected, and the database marked as schema version 1. See model/__init__.py within the application source for more information. To run the application use the standard Pylons command:: $ paster serve --reload development.ini Point your browser at the URL http://127.0.0.1:5000/ The generated project contains model and functional tests that can be run using the "nosetests" command (requires the Nose package to be installed). Documentation ------------- For more information see the BlastOff wiki at http://bitbucket.org/chrismiles/blastoff/wiki/Home or the Pylons documentation at http://pylonshq.com/ repoze.what 1.0.9 Authorization framework for WSGI applications Gustavo Narea ************************************************** repoze.what -- Authorization for WSGI applications ************************************************** :mod:`repoze.what` is an `authorization framework` for WSGI applications, based on :mod:`repoze.who` (which deals with `authentication` and `identification`). On the one hand, it enables an authorization system based on the groups to which the `authenticated or anonymous` user belongs and the permissions granted to such groups by loading these groups and permissions into the request on the way in to the downstream WSGI application. And on the other hand, it enables you to manage your groups and permissions from the application itself or another program, under a backend-independent API. For example, it would be easy for you to switch from one back-end to another, and even use this framework to migrate the data. This is just the authorization pattern it supports out-of-the-box, but you can may it support other authorization patterns with your own predicates. It's highly extensible, so it's very unlikely that it will get in your way -- Among other things, you can extend it to check for many conditions (such as checking that the user comes from a given country, based on her IP address, for example). repoze.bfg.traversalwrapper 0.3 An add-on for the repoze.bfg web framework which supplies a model graph traverser which proxies location-ignorant model objects Agendaless Consulting repoze.bfg.traversalwrapper =========================== An alternate implementation of the ``repoze.bfg.interfaces.ITraverserFactory`` (a "traverser") which wraps each traversed object in a proxy. This allows a "location-ignorant" model (a model which does not possess intrinsic ``__name__`` and ``__parent__`` attributes) to be used as the root object and as any object returned from any other model's ``__getitem__`` method during traversal. When this ITraverserFactory is registered as the traverser for a ``repoze.bfg`` application, during traversal, each object, including the root object is wrapped in a proxy. The proxy that provides the traversed object with a ``__name__`` and ``__parent__`` attribute. The ``__name__`` and ``__parent__`` attributes of the root proxy are both ``None``. The ``__name__`` of subsequently traversed object is the Unicode URL segment name which was used to look it up. The ``__parent__`` of subsequently traversed objects is the previous object traversed. In order to enable this package's ITraverserFactory, register the ``repoze.bfg.traversalwrapper.ModelGraphTraverser`` as the traversal policy, rather than the default ``ModelGraphTraverser``. To use this feature, your application will need to have a dependency on this package, as well as following stanza in its ``configure.zcml``:: <adapter factory="repoze.bfg.traversalwrapper.ModelGraphTraverser" provides="repoze.bfg.interfaces.ITraverserFactory" for="*" /> .. note:: When this ITraverserFactory is used, the intrinsic ``__name__`` or ``__parent__`` attribute of an object are ignored. Even if an object in the graph (including the root objects) has an intrinsic ``__name__`` and ``__parent__`` attribute, it will still be wrapped in a proxy that override the object's "real" ``__parent__`` and ``__name__`` attributes. repoze.bfg.traversalwrapper Changelog ===================================== 0.3 (2009-06-22) ----------------- - Compatibility with BFG 1.0a1. This version is not guaranteed to be compatible with any BFG version before 1.0a1. 0.2 (2008-05-18) ---------------- - Use dictionary return values from our ITraverser in lockstep with changes to 0.8dev. 0.1 --- - Initial release (functionality moved out of BFG core). repoze.who.plugins.beaker_tkt 0.1 Identifier (auth_tkt) plugin with beaker.session cache implementation Domen Kozar What is BeakerAuthTktPlugin? ============================ `BeakerAuthTktPlugin` acts the same way as `CookieAuthTktPlugin`, but instead of caching identity through cookie, it stores it in Beaker session. Full documentation is avaliable, please `read the documentation page on site`__. Mercurial repository is located at bitbucket.org_. .. _bitbucket.org: http://bitbucket.org/iElectric/repozewhopluginsbeaker_tkt/ .. __: http://docs.fubar.si/repoze.who.plugins.beaker_tkt/ repoze.what.plugins.redis 1.0rc1 The repoze.what Redis plugin Jonas Melian ============================ The repoze.what Redis plugin ============================ This is an adapters plugin for `repoze.what <http://what.repoze.org/docs/1.x/>`_ The Redis plugin makes *repoze.what* support sources defined in Redis key-value databases by providing one group adapter and one permission adapter. Redis ===== `Redis <http://code.google.com/p/redis/>`_ is a key-value database. It is similar to memcached but the dataset is not volatile, and values can be strings, exactly like in memcached, but also lists and sets with atomic operations to push/pop elements. In order to be very fast but at the same time persistent the whole dataset is taken in memory and from time to time and/or when a number of changes to the dataset are performed it is written asynchronously on disk. The database name is numeric; the default database is **0**. *repoze.what.plugin.redis* uses database **1** for the group adapter and database **2** for the permission adapter. The database **0** could be used for any table related to users as the sessions. Building -------- To compile the trunk version:: $ git clone git://github.com/antirez/redis.git $ cd redis $ make To update:: $ git pull && make clean && make To run the server:: $ ./redis-server The Python library is in *./client-libraries/python/* *Note*: The client-libraries directory inside the Redis distribution is only a temp thing. Little issues ------------- * If the client is disconnected after of some time of inactivity --it's configured to 300 seconds by default--, and it's called any command then it raises a *ConnectionError*. It should be rather managed from the Python driver: http://groups.google.com/group/redis-db/browse_thread/thread/2581396a6722d3f9 * The data are synchronously saved. It could be modified the *_save* function (in the Redis adapter) for that it been asynchronously saved, or for that it been saved only when a number of changes to the dataset are performed. Use === Typical usage: >>> import redis >>> from repoze.what.plugins.redis import adapters >>> group = adapters.RedisGroupAdapter(redis.Redis()) >>> permission = adapters.RedisPermissionAdapter(redis.Redis()) repoze-oauth-plugin 0.1.1 OAuth plugin for repoze.who and repoze.what Linas Juškevičius repoze-oauth-plugin =================== repoze-oauth-plugin is a repoze.who_ and repoze.what_ plugin implementing the server side of the `OAuth 1.0`_ protocol. Currently it supports only 2-legged flow where the client is at the same time a resource owner. This happens when a client application has access to the resources on the server on behalf of itself and does not need a user (human) permission for the access. You can read more about OAuth at hueniverse_ (`2-legged flow`_). Source ------ You can find the source code repository at GitHub_. Installation ------------ easy_install_:: $ <env>/bin/easy_install repoze-oauth-plugin pip_:: $ <env>/bin/pip install repoze-oauth-plugin OAuthPlugin Usage ----------------- You can create the plugin with:: >>> from repoze.who.plugins.oauth import OAuthPlugin >>> oauth_plugin = OAuthPlugin(DBSession=Session, ... Manager=MyManager, ... realm='my-realm') where: - ``Session`` is an SQLAlchemy Session bound to a valid engine. If you are configuring the plugin through the PasteDeploy configuration file this can be an `entry point`_, e.g. `myproject.model.meta:Session`. - ``Manager`` (optional) is a class that is responsible for client management in the database. Default - ``repoze.who.plugins.oauth:DefaultManager``. The Manager has to take the ``Session`` as an initialization parameter and provide a ``get_consumer_by_key(key)`` instance method. Can be provided as an entry point too. - ``realm`` (optional) - a realm identifying the protection space. The repoze.who plugin in repoze-oauth-plugin acts as an Identifier_, Authenticator_ and Challenger_. Therefore to get OAuth support you need to give it as identifier, authenticator and challenger to the repoze.who middleware_, similar to this (here we create it using repoze.what provided helper):: >>> oauth_plugin = OAuthPlugin(Session, realm='MyRealm') >>> from repoze.what.middleware import setup_auth >>> app = PluggableAuthenticationMiddleware(my_app, ... group_adapters=my_group_adapters, ... permission_adapters=my_permission_adapters, ... identifiers=[('oauth', plugin)], ... authenticators=[('oauth', plugin)], ... challengers=[('oauth', plugin)], ... **other_kwargs) However, usually you would use some higher level middleware maker. Let's take repoze.what-quickstart_ as an example:: >>> oauth_plugin = OAuthPlugin(Session, realm='MyRealm') >>> from repoze.what.plugins.quickstart import setup_sql_auth >>> app = setup_sql_auth(app, User, Group, Permission, Session, ... identifiers=[('oauth', oauth_plugin)], ... authenticators=[('oauth', oauth_plugin)], ... challengers=[('oauth', oauth_plugin)]) repoze-oauth-plugin uses oauth2_ for OAuth specific functionality and plays well with restkit_. Predicate Usage --------------- If you have set the OAuthPlugin with setup_sql_auth (or any other way that includes repoze.what support) you can use OAuth specific predicates provided by repoze-oauth-plugin. ``is_consumer([consumer_key=None])`` is a predicate that checks whether the current user is a consumer acting on behalf of itself (2-legged flow):: >>> from repoze.what.plugins.oauth import is_consumer >>> p = is_consumer() >>> p.check_authorization(environ) Traceback (most recent call last): ... repoze.what.predicates.NotAuthorizedError: The current user must be a consumer Ask for a consumer with a particular key:: >>> p = is_consumer('my-app') ``not_oauth()`` is a predicate that denies access through OAuth. All other methods are allowed (even anonymous!):: >>> from repoze.what.plugins.oauth import not_oauth >>> p = not_oauth() >>> p.check_authorization(environ_with_oauth) Traceback (most recent call last): ... repoze.what.predicates.NotAuthorizedError: Access through OAuth forbidden >>> p.check_authorization({}) # Empty environ, no user - ok! Pylons setup ------------ The following is an example setup for a Pylons application. Let's assume it is called ExampleApp. We'll use repoze.what-quickstart_ and repoze.what-pylons_:: $ <env>/bin/pip install repoze.what-quickstart repoze.what-pylons First, in your `exampleapp/config/middleware.py` file define imports:: from repoze.what.plugins.quickstart import setup_sql_auth from repoze.who.plugins.oauth import OAuthPlugin from exampleapp.model import User, Group, Permission from exampleapp.model.meta import Session then just below:: # The Pylons WSGI app app = PylonsApp(config=config) create the repoze-oauth-plugin and provide a realm and SQLAlchemy session:: oauth_plugin = OAuthPlugin(realm='exampleapp', DBSession=Session) app = setup_sql_auth(app, User, Group, Permission, Session, identifiers=[('oauth', oauth_plugin)], authenticators=[('oauth', oauth_plugin)], challengers=[('oauth', oauth_plugin)]) According to the OAuth specification in case of `401 Unauthorized` the server has to return a `WWW-Authenticate: OAuth realm="..."` header. Pylons `StatusCodeRedirect` middleware replaces the `401` response with its own custom `401` response discarding even the headers set by the downstream application. In order to avoid this StatusCodeRedirect can be configured to not intercept the `401` response. In `exampleapp/config/middleware.py` replace:: # Display error documents for 401, 403, 404 status codes (and # 500 when debug is disabled) if asbool(config['debug']): app = StatusCodeRedirect(app) else: app = StatusCodeRedirect(app, [400, 401, 403, 404, 500]) with:: # Display error documents for 400, 403, 404 status codes (and # 500 when debug is disabled) if asbool(config['debug']): app = StatusCodeRedirect(app, [400, 403, 404]) else: app = StatusCodeRedirect(app, [400, 403, 404, 500]) With the above setup you will have the OAuth consumer information in the environment whenever successful authentication happens. In order to be sure that only valid consumers can access your controllers and actions you have to protect them with repoze.what-pylons predicates:: # exampleapp/controllers/cars.py ... from repoze.what.plugins.pylonshq import ActionProtector from repoze.what.plugins.oauth import is_consumer, not_oauth class CarsController(BaseController): @ActionProtector(is_consumer) def index(self): return 'Hello, Consumer' @ActionProtector(not_oauth) def public(self): return 'Not for consumer' # exampleapp/controllers/trucks.py ... from repoze.what.plugins.pylonshq import ControllerProtector from repoze.what.plugins.oauth import is_consumer class TrucksController(BaseController): def index(self): return 'Hello, all consumers' TrucksController = ControllerProtector(is_consumer)(TrucksController) Now these actions can be accessed using restkit_:: >>> from restkit import OAuthFilter, request, oauth2 >>> consumer = oauth2.Consumer(key='the-consumer', ... secret='the-consumer-secret') >>> auth = OAuthFilter(('*', consumer)) >>> resp = request('http://localhost:5000/cars/index', filters=[auth]) >>> print resp.body .. _repoze.who: http://static.repoze.org/whodocs/ .. _repoze.what: http://what.repoze.org/docs/1.0/ .. _OAuth 1.0: http://oauth.net/core/1.0a/ .. _hueniverse: http://hueniverse.com/oauth/ .. _2-legged flow: http://hueniverse.com/oauth/guide/terminology/ .. _GitHub: http://github.com/kaukas/repoze-oauth-plugin .. _easy_install: http://peak.telecommunity.com/DevCenter/EasyInstall .. _pip: http://pip.openplans.org/ .. _entry point: http://peak.telecommunity.com/DevCenter/setuptools#entry-points .. _Identifier: http://static.repoze.org/whodocs/narr.html#identifier-plugins .. _Authenticator: http://static.repoze.org/whodocs/narr.html#authenticator-plugins .. _Challenger: http://static.repoze.org/whodocs/narr.html#challenger-plugins .. _middleware: http://static.repoze.org/whodocs/narr.html#module-repoze.who.middleware .. _repoze.what-quickstart: http://what.repoze.org/docs/plugins/quickstart/ .. _repoze.what-pylons: http://pypi.python.org/pypi/repoze.what-pylons .. _oauth2: http://pypi.python.org/pypi/oauth2 .. _restkit: http://pypi.python.org/pypi/restkit plone.transformchain 1.0b1 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 Martin Aspeli Introduction ============ This package provides a means of modifying the response from a page published with ``repoze.zope2`` or the "classic" ``ZPublisher`` before it is returned to the browser. Register a uniquely named adapter from ``(published, request)`` providing the ``ITransform`` interface. ``published`` is the published object, e.g. a view; ``request`` is the current request. The order of the transforms can be maintained using the ``order`` property of the adapter. One of three methods will be called, depending on what type of input was obtained from the publisher and/or the previous method. * transformBytes() is called if the input is a str (bytes) object * transformUnicode() is called if the input is a unicode object * transformIterable() is called if the input is another type of iterable Each stage can return a byte string, a unicode string, or an iterable. Most transformers will have a "natural" representation of the result, and will implement the respective method to return another value of the same representation, e.g. implement transformUnicode() to transform and return a unicode object. The other methods may then either be implemented to return None (do nothing) or convert the value to the appropriate type. The first transformer in the chain is likely to get: * A byte string if the transformer is running under the standard Zope 2 ZPublisher. * An iterable if the transformer is running under repoze.zope2 or another WSGI pipeline. Check ``self.request.response.getHeader('content-type')`` to see the type of result. The iterable, when unwound, will conform to this type, e.g. for text/html, ``''.join(result)`` should be an HTML string. The return value is passed to the next transform in the chain. The final transform should return a unicode string, an encoded string, or an iterable. If a byte string or unicode string is returned by the last transform in the chain, the ``Content-Length`` header will be automatically updated Return ``None`` to signal that the result should not be changed from the previous transform. Here is an example that uppercases everything:: from zope.interface import implements, Interface from zope.component import adapts from plone.transformchain.interfaces import ITransform class UpperTransform(object): implements(ITransform) adapts(Interface, Interface) # any context, any request order = 1000 def __init__(self, published, request): self.published = published self.request = request def transformBytes(self, result, encoding): return result.upper() def transformUnicode(self, result, encoding): return result.upper() def transformIterable(self, result, encoding): return [s.upper() for s in result] You could register this in ZCML like so:: <adapter factory=".transforms.UpperTransform" name="example.uppertransform" /> If you need to turn off transformations for a particular request, you can set a key in ``request.environ``:: request.environ['plone.transformchain.disable'] = True This will leave the response untouched and will not invoke any ``ITransform`` adapters at all. Changelog ========= 1.0b1 - 2010-04-21 ------------------ * Initial release repoze.bfg.htmlpage 0.3.2 Dynamic HTML pages for repoze.bfg UNKNOWN Overview ======== This package provides a page-level rendering system for the ``repoze.bfg`` web framework. It uses familiar technologies like HTML and CSS to dynamically use an existing HTML document as template. Consult the documentation for ``chameleon.html`` for information on how to write templates. Credits ------- This package was created by Malte Borch <mborch@gmail.com>, Stefan Eletzhofer <stefan.eletzhofer@inquant.de> and Christof Haemmerle <reco@nex9.com>. repoze.bfg.layouts 0.2 Dynamic layouts for repoze.bfg UNKNOWN Overview ======== ``repoze.bfg.layouts`` provides a site layout story for the ``repoze.bfg`` framework. It uses familiar technologies like CSS3 to dynamically inject dynamic content into static HTML. Consult the documentation for ``chameleon.html`` for information on how to write templates. Credits ------- This package was created by Malte Borch <mborch@gmail.com>, Stefan Eletzhofer <stefan.eletzhofer@inquant.de> and Christof Haemmerle <reco@nex9.com>. repoze.cssutils 1.0a6 CSS parsing and utilities David Pratt repoze.cssutils =============== ``repoze.cssutils`` provides css parsing and utilities for CSS 2.1 and CSS3. 1.0a6 (released 03/29/2009) - Fix bug that could lead to infinite recursion when a declaration is not terminated. Many thanks to Malthe Borche for reporting and providing fix. 1.0a5 (released 02/10/2009) - Correct packaging error 1.0a4 (released 01/09/2009) - Updated license and copyright info 1.0a3 (released 12/29/2008) - Initial release repoze.bfg.restrequest 1.0.1 a REST aware Request for implementing RESTful applications with repoze.bfg Christian Scholz Introduction ============ ``repoze.bfg.restrequest`` implements 4 additional Request types for use with RESTful applications. Imagine you want to create separate views for one resource (identified by an URL) and different HTTP methods. In a default repoze.bfg project you can e.g. write:: from repoze.bfg.restrequest import IGETRequest, IPOSTRequest from webob import Response def my_view_get(context, request): return Response("GET\n") def my_view_post(context, request): return Response("POST "+request.body+"\n") This defines one method ``my_view_get`` in case a ``GET`` request is performed on this resource and ``my_view_post`` in case a ``POST`` request is performed. You can do similar things with ``PUT`` or ``DELETE``. In order to enable these views you need to wire them in ``configure.zcml`` like this:: <!-- include to activate the event handler for marking REST requests --> <include package="repoze.bfg.restrequest" /> <bfg:view for=".models.IMyModel" request_type="repoze.bfg.restrequest.interfaces.IGETRequest" view=".views.my_view_get" /> <bfg:view for=".models.IMyModel" request_type="repoze.bfg.restrequest.interfaces.IPOSTRequest" view=".views.my_view_post" /> You can do the same using ``repoze.bfg.convention`` in which case your views would look like this:: from repoze.bfg.restrequest import IGETRequest, IPOSTRequest from webob import Response @bfg_view(request_type=IGETRequest, for_=models.IMyModel) def my_view_get(context, request): return Response("GET\n") @bfg_view(request_type=IPOSTRequest, for_=models.IMyModel) def my_view_post(context, request): return Response("POST "+request.body+"\n") Make sure you nevertheless include ``repoze.bfg.restrequest`` in your ``configure.zcml``. Testing your application ------------------------ A simple test for the above would be to start your application and use ``curl`` to see what the result is for different methods:: $ curl http://127.0.0.1:6543/ GET $ curl http://127.0.0.1:6543/ -d "posttest" POST posttest Changelog ========= 1.0 - initial release (19 Oct 2008) ------------------------------------ * Initial release 1.0.1 - package bugfixing ------------------------- * moved HISTORY.txt to main directory so that setup.py finds and packages it. compoze 0.4 Build package indexes Agendaless Consulting compoze README ============== This package provides a script for creating ``setuptools``-compatible package indexes using packages downloaded from other indexes. Please see ``docs/index.rst`` for the documentation, which can also be read online at: http://docs.repoze.org/compoze http://packages.python.org/compoze compoze Changelog ================= compoze 0.4 (2010-03-29) ------------------------ - Added global ``--use-versions`` and ``--versions-section`` options, to permit specifying requirements from the configuration file. Updated ``compoze fetch`` and ``compoze show`` to use such requirements. - Normalized options, allowing more to be set globally or in the config file: ``--index-url``, ``--find-links``, ``--fetch-site-packages``, ``--include-binary-eggs``, ``--keep-tempdir``. - Updated spelling of ``--find-link`` option to ``--find-links``. - Added a global ``--config-file`` option to permit setting options in an INI-style config file. compoze 0.3.1 (2010-03-25) -------------------------- - Fix bug in ``compoze fetch`` under recent setuptools: "AttributeError: NoneType has no attribute 'clone'". - Fix bug in ``compoze show`` under recent setuptools: "AttributeError: EmptyProvider instance has no attribute 'name'". - Further documentation improvements. compoze 0.3 (2010-03-25) ------------------------ - Added Sphinx documentation. - Switched to using ``pkginfo`` to parse package information. - Added ``pool`` command which moves all archives in the current directory to a common pool directory and symlinks them back. - Added ``show`` command, which displays locations for one or more requirements across a set of indexes. compoze 0.2 (2007-11-19) ------------------------ - Added ``--help-commands`` option to show subcommands. - Broke ``fetch`` and ``index`` out as subcommands; other commands can be registered using the pkg_resources entry point group, ``compoze_commands``. compoze 0.1 (2007-11-14) ------------------------ - Initial release. repoze.what.plugins.config 0.2.1 pastedeploy help methods for repoze.what. Jose Dinuncio repoze.what.plugins.config -- repoze.what with pasterconfig =========================================================== .. topic:: Overview ``repoze.what.plugins.config`` allows you to configure ``repoze.who`` and ``repoze.what`` using ``pastedeploy``. repoze.who and repoze.what are WSGI middleware frameworks for authentication and authorization, respectively. ``paster`` and ``pastedeploy`` allows you to configure your WSGI application via INI files. Installing repoze.what.plugins.config ===================================== You can install repoze.what.plugins.config using git:: git clone git://github.com/jdinuncio/repoze.what.plugins.config.git cd repoze.what.plugins.config python setup.py install Using repoze.what.plugins.config ================================ ``repoze.what.plugins.config`` offers a config entry point for pastedeploy to instantiate a ``repoze.who+repoze.what`` middleware. You can use it as a filter in the paster INI file:: [filter:what] use = egg:repoze.what.plugins.config#config config_file = %(here)s/what.ini who_config_file = %(here)s/who.ini The ``what.ini`` file has the same format of a who INI file, with the following additions: * You can define what plugins. * There is a special section ``what`` with ``group_adapters`` and ``permission_adapters`` entries. You can combine who.ini and what.ini in one file. If you decide to do this, remember that a ``repoze.what`` modprovider will be implicitly added to your ``repoze.who`` configuration. Example of use ============== Here is a valid what.ini config file:: [plugin:basicauth] use = repoze.who.plugins.basicauth:make_plugin realm = 'zbfg' [plugin:htpasswd] use = repoze.who.plugins.htpasswd:make_plugin check_fn = repoze.who.plugins.htpasswd:plain_check filename = %(here)s/passwd [plugin:ini_group] use = repoze.what.plugins.ini:INIGroupAdapter filename = group.ini [plugin:ini_permission] use = repoze.what.plugins.ini:INIPermissionsAdapter filename = permissions.ini [general] request_classifier = repoze.who.classifiers:default_request_classifier challenge_decider = repoze.who.classifiers:default_challenge_decider remote_user_key = REMOTE_USER [identifiers] plugins = basicauth [authenticators] plugins = htpasswd [challengers] plugins = basicauth [what] group_adapters = ini_group permission_adapters = ini_permission repoze.who.plugins.formcookie 0.3.0 Similar to RedirectingFormPlugin, but stores came_from in cookie instead of url query string Domen "iElectric" Kozar Documentation at http://docs.fubar.si/formcookie/ Source at http://www.bitbucket.org/iElectric/repozewhopluginsformcookie/ repoze.filesafe 1.0 Transaction-aware file creation Wichert Akkerman repoze.filesafe =============== repoze.filesafe provides utilities methods to handle creation of files on the filesystem safely by integrating with the ZODB package's transaction manager. It can be used in combination with repoze.tm (or repoze.tm2) for use in WSGI environments. See docs/index.rst for documentation. 1.0 --- - Made DummyDataManager transaction aware. [fschulze] 1.0a6 ----- - Fix packaging error. [wichert] 1.0a5 ----- - Add a MockFile class to help with handling of files when using the DummyDataManager. [fschulze] 1.0a4 ----- - Add a new openFile method to facilitate opening of files that have not been commited yet. [wichert] 1.0a3 ----- - Add method to facilitate unit testing of code using repoze.filesafe. [wichert] 1.0a2 ----- - Add support for Python 2.4 and 2.5. [wichert] 1.0a1 ----- - Initial Release repoze.who-friendlyform 1.0.6 Collection of repoze.who friendly form plugins Gustavo Narea ********************************************** Collection of repoze.who friendly form plugins ********************************************** repoze.who-friendlyform is a repoze.who plugin which provides a collection of developer-friendly form plugins, although for the time being such a collection has only one item. repoze.what-quickstart 1.0.8 The repoze.what Quickstart plugin Gustavo Narea ********************************* The repoze.what Quickstart plugin ********************************* This is an extras plugin for repoze.what. This plugin allows you to take advantage of a rather simple, and usual, authentication and authorization setup, in which the users' data, the groups and the permissions used in the application are all stored in a SQLAlchemy or Elixir-managed database. Put simply, it configures repoze.who and repoze.what in one go so that you can have an authentication and authorization system working quickly -- hence the name. vudo.cmf 0.2 Content management framework. UNKNOWN Overview ======== This package provides a framework for content management. repoze.what.plugins.ini 0.2.2 repoze.what pluggin with sources based on INI files. Jose Dinuncio repoze.what.plugins.ini -- Plugin for repoze.what authorization framework ========================================================================= What is repoze.what.plugins.ini? -------------------------------- repoze.what.plugins.ini is a plugin for repoze.what that offers group and permissions adapters for sources based on INI files. What is repoze.what? -------------------- From repoze.what site: repoze.what is an authorization framework for WSGI applications, based on repoze.who (which deals with authentication). On the one hand, it enables an authorization system based on the groups to which the authenticated or anonymous user belongs and the permissions granted to such groups by loading these groups and permissions into the request on the way in to the downstream WSGI application. And on the other hand, it enables you to manage your groups and permissions from the application itself or another program, under a backend-independent API. For example, it would be easy for you to switch from one back-end to another, and even use this framework to migrate the data. repoze.what can be used as authorization framework for turbogear, repoze.bfg or your own WSGI server. How to install repoze.what.plugins.ini? --------------------------------------- You can install the last stable version with easy_install:: easy_install repoze.what.plugins.ini or the developer version via git:: git clone git://github.com/jdinuncio/repoze.what.plugins.ini.git cd repoze.what.plugins.ini python setup.py install The source file format ---------------------- The format used in the source files is similar to the INI file format. The file consists in a serie of sections, each one with a section header of the form “[section-name]”, followed by entries of the form “value”. Spaces before and after section headers or entries are ignored. Characters after ”#” are ignored. An example of a group file:: [admins] rms [developers] rms linus [trolls] sballmer [python] [php] An example of a permissions file: [see-site] trolls [edit-site] admins developers [commit] developers How to use it? -------------- All you need to do is to instantiate a repoze.what middleware using repoze.what.plugins.ini.INIGroupAdapter or repoze.what.plugins.ini.INIPermissionsAdapter:: # First, we'll need a WSGI application my_app = None # Of course, you'll change None for your WSGI app # We need to set up the repoze.who components used by repoze.what for # authentication from repoze.who.plugins.htpasswd import HTPasswdPlugin, crypt_check from repoze.who.plugins.basicauth import BasicAuthPlugin htpasswd = HTPasswdPlugin('passwd', crypt_check) basicauth = BasicAuthPlugin('MyRepoze') identifiers = [('basicauth', basicauth)] authenticators = [('htpasswd', htpasswd)] challengers = [('basicauth', basicauth)] mdproviders = [] # We'll use group and permission based exclusively on INI files from repoze.what.plugins.ini import INIGroupAdapter from repoze.what.plugins.ini import INIPermissionsAdapter groups = {'all_groups': INIGroupAdapter('groups.ini')} permissions = {'all_perms': INIPermissionsAdapter('permissions.ini')} # Finally, we create the repoze.what middleware import logging from repoze.what.middleware import setup_auth middleware = setup_auth( app = my_app, group_adapters = groups, permission_adapters = permissions, identifiers = identifiers, authenticators = authenticators, challengers = challengers, mdproviders = mdproviders, log_level = logging.DEBUG ) repoze.postoffice 0.2 Provides central depot for incoming mail for use by applications. Chris Rossi ================= repoze.postoffice ================= `repoze.postoffice` provides a centralized depot for collecting incoming email for consumption by multiple applications. Incoming mail is sorted into queues according to rules with the expectation that each application will then consume its own queue. Each queue is a first-in-first-out (FIFO) queue, so messages are processed in the order received. ZODB is used for storage and is also used to provide the client interface. `repoze.postoffice` clients create a ZODB connection and manipulate models. This makes consuming the message queue in the context of a transaction, relatively simple. Setting up the depot ==================== `repoze.postoffice` assumes that a message transport agent (MTA), such as Postfix, has been configured to deliver messages to a folder using the Maildir format. Configuring the MTA is outside of the scope of this document. The depot is configured via a configuration file in ini format. The ini file consists of a single 'post office' section followed by one or more named queue sections. The 'post office' section contains information about the ZODB set up as well as the location of the incoming Maildir:: [post office] # Required parameters zodb_uri = zconfig://%(here)s/zodb.conf#main maildir = %(here)s/incoming/Maildir # Optional parameters zodb_path = /postoffice ooo_loop_frequency = 60 # 1 Hertz ooo_loop_headers = To,Subject ooo_throttle_period = 300 # 5 minutes max_message_size = 500m `zodb_uri` is interpreted using `repoze.zodbconn` and follows the format laid out there. See: http://docs.repoze.org/zodbconn/narr.html `zodb_path` is the path in the db to the postoffice queues. This parameter is optional and defaults to '/postoffice'. `maildir` is the path to the incoming Maildir format folder from which messages are pulled. `ooo_loop_frequency` specifies the threshold frequency of incoming messages from the same user to the same queue, in messages per minute. When the threshold is reached by a particular user, messages from that user will be marked as rejected for period of time in an attempt to break a possible out of office auto-reply loop. If not specified, no check is performed on frequency of incoming messages. `ooo_loop_headers` optionally causes loop detection to use the specified email headers as discriminators. If specified, these headers must match for incoming messages to trigger the ooo throttle. If not specified, no header matching is done, and messages need only be sent from the same user to the same queue to trigger the throttle. `ooo_throttle_period` specifies the amount of time, in minutes, for which a user's incoming mail will be marked as rejected if loop detection is in use and the user reaches the `ooo_loop_frequency` threshold. Defaults to 5 minutes. If `ooo_loop_frequency` is not set, this setting has no effect. `max_message_size` sets the maximum size, in bytes, of incoming messages. Messages which exceed this limit will have their payloads discarded and will be marked as rejected. The suffixes 'k', 'm' or 'g' may be used to specify that the number of bytes is expressed in kilobytes, megabytes or gigabytes, respectively. A number without suffix will be interpreted as bytes. If not set, no limit will be imposed on incoming message size. Each message queue is configured in a section with the prefix 'queue:':: [queue:Customer A] filters = to_hostname: app.customera.com [queue:Customer B] filters = to_hostname: .customerb.com Filters are used to determine which messages land in which queues. When a new message enters the system each queue is tried in the order specified in the ini file until a match is found or until all of the queues have been tried. For each queue each filter for that queue is processed. In order to match for a queue a message must match all filters for that queue. At the time of this writing only a single filter is implemented: `to_hostname`. This filter matches the hostname of the email address in the 'To' header of the message. Hostnames which beging with a period will match any hostname that ends with the specified name, ie '.example.com' matches 'example.com' and 'app.example.com'. If the hostname does not begin with a period it must match exactly. Populating Queues ================= Queues are populated using the `postoffice` console script that is provided when the `repoze.postoffice` egg is installed. This script reads messages from the incoming maildir and imports them into the ZODB-based depot. Messages are matched and placed in appropriate queues. Messages which do not match any queues are erased. There are no required arguments to the script--if it can find it's .ini file, it will work: $ bin/postoffice The `postoffice` script will search for an ini file named 'postoffice.ini' first in the current directory, then in an 'etc' folder in the current directory, then an 'etc' folder that is a sibling of the 'bin' folder which contains the `postoffice` script and then, finally, in '/etc'. You can also use a non-standard location for the ini file by passing the path as an argument to the script: $ bin/postoffice -C path/to/config.ini Use the '-h' or '--help' switch to see all of the options available. Out of Office Loop Detection ============================ `repoze.postoffice` does attempt to address out of office loops. An out of office loop can occur when `repoze.postoffice` is used to populate content in an application which generates an email to alert users of the new content. Essentially, a poorly behaved email client will respond to the new content alert email with an out of office reply which in turn causes more content to be created and another alert email to be sent. Without some form of loop detection, this can lead to a large amount of junk content being generated very quickly. When a new email enters the system, `repoze.postoffice` first checks for some headers that could be set by well behaved MTA's to indicate automated responses and marks as rejected messages which match these known heuristics. First, the non-standard, but widely supported, 'Precedence' header is checked and messages with a precedence of 'bulk', 'junk', or 'list' are marked as rejected. Next `repoze.postoffice` will check for the presence of the 'Auto-Submitted' header which is described in rfc3834 and is standard, but not yet widely supported. Messages containing this header are marked. In either of these two cases, the incoming message is marked by adding the header:: X-Postoffice-Rejected: Auto-response Out of office messages sent by certain clients (Microsoft) will typically not use either of the above standards to indicate an automated reply. As a last line of defense, `repoze.postoffice` also tracks the frequency of incoming mail by email address and, optionally, other headers specified by the 'ooo_loop_headers' configuration option. When the number of messages arriving from the same user surpasses a particular, assumedly inhuman, threshold, a temporary block is placed on messages from that user, such that all messages from that user are marked as rejected for a certain period of time, hopefully breaking the auto reply feedback loop. Messages which trigger are fall under a throttle are marked with header:: X-Postoffice-Rejected: Throttled Messages marked with the 'X-Postoffice-Rejected' header are still conveyed to the client. It is up to the client to check for this header and take appropriate action. This allows the client to choose and take appropriate action, such as bouncing with a particular bounce message, etc. Message Size Limit ================== If 'max_message_size' is specified in the configuration, messages which exceed this size will have their payloads (body and any attachments) discarded and will be marked with the header: X-Postoffice-Rejected: Maximum Message Size Exceeded The trimmed message is still conveyed to the client, which should check for the 'X-Postoffice-Rejected' header and take appropriate action, possibly including bouncing the message with an appropriate bounce message. Consuming Queues ================ Client applications consume message queues by establishing a connection to the ZODB which houses the depot and interacting with queue and message objects. `repoze.postoffice.queue` contains a helper method, `open_queue` which given connection information can open the connection for you and return a Queue instance:: from my.example import process_message from my.example import validate_message from repoze.postoffice.queue import open_queue import sys import transaction ZODB_URI = zconfig://%(here)s/zodb.conf#main queue_name = 'my queue' queue = open_queue(ZODB_URI, queue_name, path='/postoffice') while queue: message = queue.pop_next() if not validate_message(message): queue.bounce(message, 'Message is invalid.') try: process_message(message) transaction.commit() except: transaction.abort() queue.quarantine(message, sys.exc_info()) transaction.commit() 0.2 (2010-06-29) ---------------- - Fixed bug in parsing headers with no values. - Added ability to use arbitrary message headers as discriminator values in out of office loop detection. - When messages exceed maximum message size, are throttled or are found to be an auto-response, they are no longer discarded. Instead these messages get an 'X-Postoffice-Rejected' header added where the value gives the reason for rejection. These messages are then consumable by clients in the normal way. It is up to the client to detect the 'X-Postoffice-Rejected' header and take appropriate action. This change was made to allow the client to determine what, if any, sort of bounce message should be generated if any of these conditions are true. 0.1 (2010-06-03) ---------------- - Initial Release. repoze.who-testutil 1.0 Test utilities for repoze.who-powered applications Gustavo Narea ************************************************** Test utilities for repoze.who-powered applications ************************************************** repoze.who-testutil is a repoze.who plugin which modifies repoze.who's original middleware to make it easier to forge authentication, without bypassing identification (this is, running the metadata providers). It's been created to ease testing of repoze.who-powered applications, in a way independent of the identifiers, authenticators and challengers used originally by your application, so that you won't have to update your test suite as your application grows and the authentication method changes. repoze.what.plugins.ip 0.1.4.1 ip based restrictions for repoze.what. Vince Spicer ip based repoze restrictions Ex: ip_from(['127.0.0.1', '192.168.0.0/24']) repoze.what.plugins.ip 0.2 ip based restrictions for repoze.what. Vince Spicer repoze.what.plugins.ip ====================== It is a repoze.what_ plugin that provides an ip_from predicate. Installation ------------ easy_install_:: $ <env>/bin/easy_install repoze.what.plugins.ip pip_:: $ <env>/bin/pip install repoze.what.plugins.ip Source ------ The source code can be found at code.google.com_. Usage ----- ``ip_from([allowed=None], [proxies=None])`` checks whether REMOTE_ADDR in the environment points to an allowed IP address. If HTTP_X_FORWARDED_FOR is set in the environment (meaning proxy access) then REMOTE_ADDR is treated as a proxy address and HTTP_X_FORWARDED_FOR as an originating IP address. ``allowed`` optional, default - ``None`` A list of IPs to allow access. Can be a string which is then interpreted as a single IP address ``proxies`` optional, default - ``None`` If a list or tuple provided then treated as a list of authorized proxy IP addresses. If a string or unicode provided then treated as a single IP address. Any other value - ``bool(proxies) == True`` means that all proxies are accepted You can filter the incoming IP address:: >>> from repoze.what.plugins.ip import ip_from >>> p = ip_from(allowed=['192.168.1.1']) >>> env = {'REMOTE_ADDR': '192.168.1.1'} >>> p.is_met(env) True >>> env = {'REMOTE_ADDR': '192.168.1.10'} >>> p.is_met(env) False By default proxy access is disabled. You can enable it with ``proxies=True``:: >>> p = ip_from(allowed=['192.168.0.0/24'], proxies=True) >>> env = { ... 'REMOTE_ADDR': '192.168.1.1', # proxy ... 'HTTP_X_FORWARDED_FOR': '192.168.1.5' # origin ... } >>> p.is_met(env) True And you can also explicitly specify proxies to allow:: >>> p = ip_from(allowed='192.168.1.5', proxies=['192.168.0.0/24']) >>> env = { ... 'REMOTE_ADDR': '192.168.1.1', # proxy ... 'HTTP_X_FORWARDED_FOR': '192.168.1.5' # origin ... } >>> p.is_met(env) True .. _repoze.what: http://what.repoze.org/docs/1.0/ .. _easy_install: http://peak.telecommunity.com/DevCenter/EasyInstall .. _pip: http://pip.openplans.org/ .. _code.google.com: http://code.google.com/p/repoze-what-plugins-ip/ repoze.bfg.chameleon_genshi 0.3 chameleon.genshi template bindings for the repoze.bfg web framework Agendaless Consulting repoze.bfg.chameleon_genshi =========================== Bindings for Chameleon Genshi-style templating support under `repoze.bfg <http://bfg.repoze.org/>`_. See the `Chameleon website <http://chameleon.repoze.org>`_ for ``chameleon.genshi`` templating language details. The API for use of ``repoze.bfg.chameleon_genshi`` under BFG is identical to the one used for `chameleon.zpt`` templates as documented in the "Templating" chapter of the `BFG docs <http://docs.repoze.org/bfg/1.3/narr/templates.html#chameleon-zpt-templates>`_. Only the templating language itself (Genshi vs. ZPT) and import locations (r.b.chameleon_genshi vs. r.b.chameleon_zpt) differ. An example:: from repoze.bfg.chameleon_genshi import render_template_to_response render_template_to_response('relative/path/to/template') ``relative/path/to/template`` is relative to the package directory in which the above code is defined. See also the ``render_template`` and ``get_template`` APIs exposed by the ``repoze.bfg.chameleon_genshi`` package, which serve the same purpose as their brethren in ``repoze.bfg.chameleon_zpt``. Genshi templates can also be used as a BFG "renderer" when you use ``repoze.bfg.chameleon_genshi``. The easiest way to allow for this is to use the following ZCML in your application's ``configure.zcml``:: <include package="repoze.bfg.chameleon_genshi"/> Once your application has been set up to process this ZCML, your application can point at ``chameleon.genshi`` templates that have the ``.genshi`` file extension from within ``@bfg_view`` directives or ZCML ``view`` directives in your application. For example:: @bfg_view(renderer='templates/foo.genshi') def someview(request): .... Or:: <view renderer="templates/foo.genshi" view=".views.someview"/> If you'd rather not use a ``.genshi`` extension for your ``chameleon.genshi`` templates, or if you'd rather not use ZCML to do registration, you can explicitly register a renderer using the ``add_renderer`` method of a "configurator". To do so, in the ``run.py`` of your BFG application, in the function called at startup, which uses a ``repoze.bfg.configuration.Configurator`` as ``config``:: from repoze.bfg.chameleon_genshi import renderer_factory config.add_renderer('.cgenshi', renderer_factory) Once you've registered ``.cgenshi`` as a renderer in a view configuration, you can do the following:: @bfg_view(renderer='templates/foo.cgenshi') def someview(request): .... Misc ---- By default, Chameleon's Genshi XIncludes support cannot resolve ``repoze.bfg`` "resource specifications" (e.g. ``my_package:foo/bar.genshi``). In order to activate an XIncludes class that understands repoze.bfg resource specifications, call the ``repoze.bfg.chameleon_genshi.XIncludes.activate`` method before using any templates (e.g., at process startup time):: from repoze.bfg.chameleon_genshi import XIncludes XIncludes.activate() This will replace the XIncludes helper class for all consumers of Chameleon in the process. repoze.bfg.chameleon_genshi =========================== 0.3 (2010-07-09) ---------------- - By default, Chameleon's Genshi XIncludes support cannot resolve ``repoze.bfg`` "resource specifications" (e.g. ``my_package:foo/bar.genshi``). In order to activate an XIncludes class that understands repoze.bfg resource specifications, call the ``repoze.bfg.chameleon_genshi.XIncludes.activate`` method before using any templates (e.g., at process startup time):: from repoze.bfg.chameleon_genshi import XIncludes XIncludes.activate() This will replace the XIncludes helper class for all consumers of Chameleon in the process. - Depend on Chameleon >= 1.2.8 (replaceable XIncludes class). 0.2 (2010-06-15) ---------------- - Bring up to speed with BFG 1.3.X. 0.1 (2009-05-02) ---------------- - Initial release (break code out of BFG core). islay.auth 0.1 An unobtrusive authentication framework for WSGI stacks. Matthew Wilkes islay.auth ========== islay.auth is a very basic authentication middleware designed to work well within the WSGI specification. As not everything that works well in theory also works well in practise the interfaces it uses are a strict subset of those used by repoze.who, so any plugin that works for islay.auth should work seamlessly in repoze.who which provides more features that may be of practical use. islay.auth will not scribble on the environ, it will only use HTTP standards. That means it works by faking HTTP basic auth rather than simply providing the details requested of it. For convenience it also provides REMOTE_USER in-keeping with the de facto standard in use by Apache. There are three types of plugin available: - IIdentifier takes a request and manipulates its credentials. As well as extracting the credentials dictionary it provides helper methods for returning the appropriate headers to users to cause them to log in or out. - IAuthenticator verifies that the extracted credentials correspond to a real user. - IChallenger plugins take over in the case of a 401 response from the underlying application. Release notes ============= 0.1 --- - Basic implementation and tests. - Does not send WWW-Authentiate yet. - Alpha quality repoze.what.plugins.xml 1.0rc1 The repoze.what XML plugin Gustavo Narea ************************** The repoze.what XML plugin ************************** This is an adapters plugin for repoze.what. Supported source formats ======================== A sample group source may look like this:: <?xml version="1.0" encoding="UTF-8"?> <groups> <group name="admins"> <member name="rms" /> </group> <group name="developers"> <member name="rms" /> <member name="linus" /> </group> <group name="trolls"> <member name="sballmer" /> </group> <group name="python"> <!-- An empty group --> </group> <group name="php"> <!-- An empty group --> </group> </groups> A sample permission source may look like this:: <?xml version="1.0" encoding="UTF-8"?> <permissions> <permission name="edit-site"> <group name="admins" /> <group name="developers" /> </permission> <permission name="commit"> <group name="developers" /> </permission> <permission name="see-site"> <group name="trolls" /> </permission> </permissions> repoze.configuration 0.7 A configuration system using YAML and entry points Agendaless Consulting repoze.configuration README =========================== ``repoze.configuration`` is a package that software developers can use as a configuration system. It allows the use of ``YAML`` as a configuration language. Application-defined "directives" can be plugged in to ``repoze.configuration`` using one or more Python setuptools entry points. For example, you could make sense out of the following YAML using repoze.configuration and a custom "appsettings" directive:: --- !appsettings port_number = 8080 reload_templates = true --- !include filename = anotherfile.yml Please see docs/index.rst or `http://docs.repoze.org/configuration <http://docs.repoze.org/configuration>`_ for more documentation. repoze.configuration Changelog ============================== 0.7 (2010-02-24) ---------------- - Allow ``repoze.configuration.context.Context`` constructor to take arbitrary keyword arguments. These kw arguments are added to the instance ``__dict__`` of the result context object. - The return value of ``repoze.configuration.context.Context.execute`` is no longer the ``registry`` attribute of the context object; it is instead ``None``. The ``registry`` object is no longer "special". 0.6 (2009-12-30) ---------------- - When ``context.action`` was called with a ``None`` discriminator (the default), it would conflict with other actions that did not supply a discriminator either. - If a ``repoze.configuration.directive`` entry point name begins with the characters 'tag:', treat the name as a YAML tag URI. YAML tag URIs can be aliased at the top of YAML files to shorter ``!bang!`` names via a YAML %TAG directive (see `YAML global tag prefix documentation <http://www.yaml.org/spec/1.2/spec.html#ns-global-tag-prefix>`_. The intent is to encourage directive writers to register both a "short name" (a word) and a tag URI for the same entry point function. Doing so means that a config file writer can optionally use a tag URI (``!<tag:repoze.org,2009:pypes/server>``) in place of a "short name" (``!server``) when the short version can't be used due to a conflict between two directives in separate packages that share the same short name. For example, an application might register both ``server = pypes.deploy.directives:server`` and ``tag:repoze.org,2009:pypes/server = pypes.deploy.directives:server`` in a ``repoze.configuration.directive`` section within ``setup.py``. A config file that used the above entry points might equivalently use any of the three below forms as necessary within a given YAML file:: # tag alias %TAG !pypes! tag:repoze.org,2009:pypes/ # short name --- !server name: main port: 8082 host: 0.0.0.0 # rely on tag expansion from %TAG directive --- !pypes!server name: main port: 8082 host: 0.0.0.0 # use literal tag URI --- !<tag:repoze.org,2009:pypes/server> name: main port: 8082 host: 0.0.0.0 0.5 (2009-07-26) ---------------- - Add documentation about interpolation. - Show only line numbers in error reports on console (previously both line numbers and column numbers were reported, but the column numbers seem to be meaningless in most debugging scenarios). - Fix an off by one error in line number reporting in errors. - Interpolation variables now try to use the registry first, but fall back to "stack" values; the most important of which is ``%(here)s``; this interpolation variable can be used in any config file. It will be the absolute path to the parent directory of the configuration file in which it was declared. Any stack variable will be overridden permanently (for interpolation purposes) by a registry variable. 0.4 (2009-07-25) ---------------- - Totally backwards incompatible. - Instead of accepting "context", "structure" and "node", directives now accept "declaration" objects. A declaration object has most of the methods that used to be supplied by the "context", and some new ones. The docs have been updated. 0.3 (2009-07-24) ---------------- - Backwards incompatibility: directives must now accept three arguments: context, structure, and node (previously they had only accepted context and structure). - ``error`` method added to context. - Make discriminator conflict detection actually work. - Show actual lines from conflicting files when possible during a discriminator conflict. - Ignore import errors when trying to resolve entry point loads. - Add a ``popvalue`` method to the context; it works like ``getvalue`` except it pops the value out of the structure supplied instead of just getting it. - It was not possible to resolve the single dot ``.`` using repoze.configuration.context.Context.resolve to the current package. - Using a Python %(interpolation)s marker in any string value allows you to replace values in strings. For example, using "%(here)s" in a string value would attempt to resolve the name "here" from the registry as a key. - Use pyyaml's SafeLoader rather than Loader: we don't really need to be able to construct arbitrary Python objects. 0.2 (2009-07-13) ---------------- - Trying to read any directive section that wasn't a YAML mapping caused a TypeError (e.g. ``construct_scalar takes no argument 'deep'``). 0.1 (2009-06-22) ---------------- - Initial release. repoze.bfg.chameleon_genshi 0.2 chameleon.genshi template bindings for the repoze.bfg web framework Agendaless Consulting repoze.bfg.chameleon_genshi =========================== Bindings for Chameleon Genshi-style templating support under `repoze.bfg <http://bfg.repoze.org/>`_. See the `Chameleon website <http://chameleon.repoze.org>`_ for ``chameleon.genshi`` templating language details. The API for use of ``repoze.bfg.chameleon_genshi`` under BFG is identical to the one used for `chameleon.zpt`` templates as documented in the "Templating" chapter of the `BFG docs <http://docs.repoze.org/bfg/1.3/narr/templates.html#chameleon-zpt-templates>`_. Only the templating language itself (Genshi vs. ZPT) and import locations (r.b.chameleon_genshi vs. r.b.chameleon_zpt) differ. An example:: from repoze.bfg.chameleon_genshi import render_template_to_response render_template_to_response('relative/path/to/template') ``relative/path/to/template`` is relative to the package directory in which the above code is defined. See also the ``render_template`` and ``get_template`` APIs exposed by the ``repoze.bfg.chameleon_genshi`` package, which serve the same purpose as their brethren in ``repoze.bfg.chameleon_zpt``. Genshi templates can also be used as a BFG "renderer" when you use ``repoze.bfg.chameleon_genshi``. The easiest way to allow for this is to use the following ZCML in your application's ``configure.zcml``:: <include package="repoze.bfg.chameleon_genshi"/> Once your application has been set up to process this ZCML, your application can point at ``chameleon.genshi`` templates that have the ``.genshi`` file extension from within ``@bfg_view`` directives or ZCML ``view`` directives in your application. For example:: @bfg_view(renderer='templates/foo.genshi') def someview(request): .... Or:: <view renderer="templates/foo.genshi" view=".views.someview"/> If you'd rather not use a ``.genshi`` extension for your ``chameleon.genshi`` templates, or if you'd rather not use ZCML to do registration, you can explicitly register a renderer using the ``add_renderer`` method of a "configurator". To do so, in the ``run.py`` of your BFG application, in the function called at startup, which uses a ``repoze.bfg.configuration.Configurator`` as ``config``:: from repoze.bfg.chameleon_genshi import renderer_factory config.add_renderer('.cgenshi', renderer_factory) Once you've registered ``.cgenshi`` as a renderer in a view configuration, you can do the following:: @bfg_view(renderer='templates/foo.cgenshi') def someview(request): .... repoze.bfg.chameleon_genshi =========================== 0.2 (2010-06-15) ---------------- - Bring up to speed with BFG 1.3.X. 0.1 (2009-05-02) ---------------- - Initial release (break code out of BFG core). repoze.what.plugins.sql 1.0 The repoze.what SQL plugin Gustavo Narea ************************** The repoze.what SQL plugin ************************** This is an adapters plugin for repoze.what. The SQL plugin makes repoze.what support sources defined in SQLAlchemy-managed databases by providing one group adapter, one permission adapter and one utility to configure both in one go (optionally, when the group source and the permission source have a relationship). repoze.bfg.traversaladapter 0.1 Alternative model graph traverser for the repoze.bfg web framework which allows registering arbitrary adapters for the type or interface of model objects encountered during traversal. F. Oliver Gathmann repoze.bfg.traversaladapter =========================== An alternate implementation of the ``repoze.bfg.interfaces.ITraverserFactory`` (a "traverser") which allows you to register an adapter factory for the type or interface(s) of objects encountered during traversal. This is a generalization of the ``repoze.bfg.traversalwrapper`` package which automatically wraps each traversed object into a location-aware proxy. To enable this custom traverser factory, you need to add a dependency on ``repoze.bfg.traversaladapter`` to your application and replace the default traverser factory in the ``configure.zcml`` configuration file like this: :: <adapter factory="repoze.bfg.traversaladapter.ModelGraphTraverser" provides="repoze.bfg.interfaces.ITraverserFactory" for="*" /> Given a simple factory for adapters for a model class ``mymodule.Foo`` defined in the module ``mymodule`` like this :: def foo_factory(foo, parent, name): return FooAdapter(foo, parent, name) you could then register ``foo_factory`` as a traversal adapter factory as follows: :: <adapter factory="mymodule.foo_factory" provides="repoze.bfg.traversaladapter.ITraversalAdapterFactory" for="mymodule.Foo" /> If ``Foo`` was implementing the interface ``mymodule.IFoo``, the following registration would also work: :: <adapter factory="mymodule.foo_factory" provides="repoze.bfg.traversaladapter.ITraversalAdapterFactory" for="mymodule.IFoo" /> During traversal of your ``repoze.bfg`` application, each object of type ``Foo`` will then automatically be wrapped in a ``FooAdapter`` instance. Note that the registered factory always gets the current model object, its parent and its name passed as arguments. If your ``FooAdapter`` class was set up to receive a ``Foo`` instance, a parent object, and a name string in its constructor like so :: class FooAdapter(object): def __init__(self, foo, parent, name): self.foo = foo self.parent = parent self.name = name you could register the adapter class itself as the adapter factory. See the ``repoze.bfg.traversaladapter.tests.TraversalAdapterTests`` module for further examples. zopyx.smartprintng.server 0.6.6 ZOPYX SmartPrintNG Server Andreas Jung zopyx.smartprintng.server ========================= A repoze.bfg based server implementation for the SmartPrintNG framework. The SmartPrintNG server is part of the SmartPrintNG web-to-print solution of ZOPYX. Requirements ============ * Python 2.6 (no Python 3 support) Installation ============ - create an ``virtualenv`` environment (Python 2.6) - either within your current (empty) directory or by letting virtualenv create one for you. (``easy_install virtualenv`` if ``virtualenv`` is not available on your system):: virtualenv --no-site-packages . or:: virtualenv --no-site-packages smartprintng - install ``repoze.bfg`` as a dependency) :: bin/easy_install repoze.bfg bin/easy_install repoze.bfg.xmlrpc - install the SmartPrintNG server:: bin/easy_install zopyx.smartprintng.server - create a ``server.ini`` configuration file (and change it according to your needs):: [DEFAULT] debug = true [app:main] use = egg:zopyx.smartprintng.server#app reload_templates = true debug_authorization = false debug_notfound = false [server:main] use = egg:Paste#http host = 127.0.0.1 port = 6543 - start the server (in foreground):: bin/paster serve server.ini - or start it in background:: bin/paster serve server.ini --daemon Upgrading ========= For upgrading an existing SmartPrintNG server you should try the following inside your virtualenv environment:: bin/easy_install -U zopyx.smartprintng.server bin/easy_install -U zopyx.convert2 XMLRPC API ========== The SmartPrintNG server exposes several methods through XMLRPC:: def convertZIP(auth_token, zip_archive, converter_name): """ 'zip_archive' is ZIP archive (encoded as base-64 byte string). The archive must contain exactly *one* HTML file to be converted including all related resources like stylesheets and images. All files must be stored flat within the archive (no subfolders). All references to externals resources like the 'src' attribute of the IMG tag or references to the stylesheet(s) must use relative paths. The method returns the converted output file also as base64-encoded ZIP archive. """ def convertZIPEmail(auth_token, context, zip_archive, converter_name='pdf-prince', sender=None, recipient=None, subject=None, body=None): """ Similar to convertZIP() except that this method will send the converted output document to a recipient by email. 'subject' and 'body' parameters *must* be utf-8 encoded. """ def availableConverters(): """ Returns a list of available converter names on the SmartPrintNG backend. """ def authenticate(username, password): """ Log into the server. Returns an auth_token. authenticate() must be called before calling any of the methods above. """ def ping(): """ says 'pong' - or something similar """ Email configuration =================== For using the email support through the ``convertZIPEmail()`` the email server must be configured through a dedicated configuration file. An ``email.ini`` may look like this:: [mail] hostname = smtp.gmail.com username = some_username password = some_password force_tls = False no_tls = False You have to pass the name of the email configuration file to ``paster`` when starting then server:: bin/paster serve server.ini mail_config=/path/to/email.ini Support ======= Support for SmartPrintNG server is currently only available on a project basis. Contact ======= | ZOPYX Ltd. & Co. KG | c/o Andreas Jung, | Charlottenstr. 37/1 | D-72070 Tuebingen, Germany | E-mail: info at zopyx dot com | Web: http://www.zopyx.com Changelog ========= 0.6.6 (2010/05/15) ------------------ * include conversion result into ZIP file 0.6.5 (2010/02/04) ------------------ * fixed racing condition in cleanup code 0.6.4 (2009/12/25) ------------------ * minor fixes * documentation cleanup 0.6.3 (2009/11/29) ------------------ * compatiblity with BFG 1.2 0.6.1 (2009/10/04) ------------------ * fixed bug in code for cleaning up the spool_directory 0.6.0 (2009/09/15) ------------------ * authentication and authorization support 0.5.2 (2009/09/05) ------------------ * adjusted to newest zopyx.convert2 version 0.6.0 (2009/09/15) ------------------ * added authentication and authorization support 0.5.2 (2009/09/05) ------------------ * adjusted to newest zopyx.convert2 version >>>>>>> .merge-right.r103965 0.5.1 (2009/08/01) ------------------ * added convertZIPandRedirect() method * added deliver() method * moved base.ServerCore to models.py * delivered files must be younger than 'delivery_max_age' seconds * cleanup code * internal refactoring * more tests 0.5.0 (2009/07/23) ------------------ * now requires Python 2.6 0.4.3 (2009/07/22) ------------------ * removed most of the ZCML configuration * tests, tests, tests 0.4.2 (2009/07/19) ------------------ * switching back to zope.sendmail * implemented asynchronous mail delivery on top of zope.sendmail 0.4.1 (2009/07/19) ------------------ * using repoze.sendmail 0.4.0 (2009/07/19) ------------------ * added convertZIPEmail() API 0.3.4 (2009/07/13) ------------------ * updated documentation 0.3.3 (2009/07/12) ------------------ * fix for missing BASE tag within HTML files 0.3.2 (2009/07/12) ------------------ * better logging 0.3.1 (2009/07/08) ------------------ * disabled check for maximum size of the request within parse_xmlrpc_request() since 8MB is too small for us 0.3.0 (2009/07/06) ------------------ * switched to repoze.bfg 0.2.0 (2009/07/06) ------------------ * improved handling of temporary directories 0.1.2 (2009/07/05) ------------------ * improved handling of temporary directories 0.1.1 (2009/07/05) ------------------ * improved logging and error handling 0.1 (2009/07/05) ---------------- * Initial release repoze.who.plugins.recaptcha 0.2 recaptcha repoze.who plugin implementation Domen **repoze.who.recaptcha** implements server side of the recaptcha API. This ``IAuthenticator`` plugin examines environment for recaptcha form values and requests verification. **repoze.who.recaptcha** works based on form_handler condition: if form_handler parameter is not given, always perform authentication. if form_handler parameter is given, perform authentication only when one of the form_handler values (separated by space) matches the absolute URL where the form is processed. If the validation succeeds, no action is taken. Otherwise error is passed to ``environ['repoze.who.error']`` and ``HTTPUnauthorzied(401)`` is triggered. .. _bitbucket.org: http://www.bitbucket.org/iElectric/repozewhorecaptcha/ Public Mercurial repo is avaliable at bitbucket.org_ :: # sample .ini configuration [plugin:recaptcha] use = repoze.who.plugins.captcha:make_authentication_plugin private_key = si3di5ndlam3x44d #optional form_handler = /process /login /admin [authenticators] plugins = recaptcha CHANGELOG: =========== 0.1 - 21.09.2008 ------------------ * Inital release 0.2 - 23.09.2008 ------------------ * New: optional form_handler parameter (make validation optional) * New: unittests * Change: ident fixes * Change: use repoze.who.logger zopyx.smartprintng.server 0.6.7 ZOPYX SmartPrintNG Server Andreas Jung zopyx.smartprintng.server ========================= A repoze.bfg based server implementation for the SmartPrintNG framework. The SmartPrintNG server is part of the SmartPrintNG web-to-print solution of ZOPYX. Requirements ============ * Python 2.6 (no Python 3 support) Installation ============ - create an ``virtualenv`` environment (Python 2.6) - either within your current (empty) directory or by letting virtualenv create one for you. (``easy_install virtualenv`` if ``virtualenv`` is not available on your system):: virtualenv --no-site-packages . or:: virtualenv --no-site-packages smartprintng - install ``repoze.bfg`` as a dependency) :: bin/easy_install repoze.bfg bin/easy_install repoze.bfg.xmlrpc - install the SmartPrintNG server:: bin/easy_install zopyx.smartprintng.server - create a ``server.ini`` configuration file (and change it according to your needs):: [DEFAULT] debug = true [app:main] use = egg:zopyx.smartprintng.server#app reload_templates = true debug_authorization = false debug_notfound = false [server:main] use = egg:Paste#http host = 127.0.0.1 port = 6543 - start the server (in foreground):: bin/paster serve server.ini - or start it in background:: bin/paster serve server.ini --daemon Upgrading ========= For upgrading an existing SmartPrintNG server you should try the following inside your virtualenv environment:: bin/easy_install -U zopyx.smartprintng.server bin/easy_install -U zopyx.convert2 XMLRPC API ========== The SmartPrintNG server exposes several methods through XMLRPC:: def convertZIP(auth_token, zip_archive, converter_name): """ 'zip_archive' is ZIP archive (encoded as base-64 byte string). The archive must contain exactly *one* HTML file to be converted including all related resources like stylesheets and images. All files must be stored flat within the archive (no subfolders). All references to externals resources like the 'src' attribute of the IMG tag or references to the stylesheet(s) must use relative paths. The method returns the converted output file also as base64-encoded ZIP archive. """ def convertZIPEmail(auth_token, context, zip_archive, converter_name='pdf-prince', sender=None, recipient=None, subject=None, body=None): """ Similar to convertZIP() except that this method will send the converted output document to a recipient by email. 'subject' and 'body' parameters *must* be utf-8 encoded. """ def availableConverters(): """ Returns a list of available converter names on the SmartPrintNG backend. """ def authenticate(username, password): """ Log into the server. Returns an auth_token. authenticate() must be called before calling any of the methods above. """ def ping(): """ says 'pong' - or something similar """ Email configuration =================== For using the email support through the ``convertZIPEmail()`` the email server must be configured through a dedicated configuration file. An ``email.ini`` may look like this:: [mail] hostname = smtp.gmail.com username = some_username password = some_password force_tls = False no_tls = False You have to pass the name of the email configuration file to ``paster`` when starting then server:: bin/paster serve server.ini mail_config=/path/to/email.ini Support ======= Support for SmartPrintNG server is currently only available on a project basis. Contact ======= | ZOPYX Limited | c/o Andreas Jung, | Charlottenstr. 37/1 | D-72070 Tuebingen, Germany | E-mail: info at zopyx dot com | Web: http://www.zopyx.com Changelog ========= 0.6.7 (2010/07/18) ------------------ * adjusted company name 0.6.6 (2010/05/15) ------------------ * include conversion result into ZIP file 0.6.5 (2010/02/04) ------------------ * fixed racing condition in cleanup code 0.6.4 (2009/12/25) ------------------ * minor fixes * documentation cleanup 0.6.3 (2009/11/29) ------------------ * compatiblity with BFG 1.2 0.6.1 (2009/10/04) ------------------ * fixed bug in code for cleaning up the spool_directory 0.6.0 (2009/09/15) ------------------ * authentication and authorization support 0.5.2 (2009/09/05) ------------------ * adjusted to newest zopyx.convert2 version 0.6.0 (2009/09/15) ------------------ * added authentication and authorization support 0.5.2 (2009/09/05) ------------------ * adjusted to newest zopyx.convert2 version 0.5.1 (2009/08/01) ------------------ * added convertZIPandRedirect() method * added deliver() method * moved base.ServerCore to models.py * delivered files must be younger than 'delivery_max_age' seconds * cleanup code * internal refactoring * more tests 0.5.0 (2009/07/23) ------------------ * now requires Python 2.6 0.4.3 (2009/07/22) ------------------ * removed most of the ZCML configuration * tests, tests, tests 0.4.2 (2009/07/19) ------------------ * switching back to zope.sendmail * implemented asynchronous mail delivery on top of zope.sendmail 0.4.1 (2009/07/19) ------------------ * using repoze.sendmail 0.4.0 (2009/07/19) ------------------ * added convertZIPEmail() API 0.3.4 (2009/07/13) ------------------ * updated documentation 0.3.3 (2009/07/12) ------------------ * fix for missing BASE tag within HTML files 0.3.2 (2009/07/12) ------------------ * better logging 0.3.1 (2009/07/08) ------------------ * disabled check for maximum size of the request within parse_xmlrpc_request() since 8MB is too small for us 0.3.0 (2009/07/06) ------------------ * switched to repoze.bfg 0.2.0 (2009/07/06) ------------------ * improved handling of temporary directories 0.1.2 (2009/07/05) ------------------ * improved handling of temporary directories 0.1.1 (2009/07/05) ------------------ * improved logging and error handling 0.1 (2009/07/05) ---------------- * Initial release ClueBzrServer 0.2 A standalone server application for serving up Bazaar repositories over HTTP Rocky Burt .. -*-rst-*- ============= ClueBzrServer ============= Introduction ============ ClueBzrServer is a http server designed to serve up arbitrary bzr directories in configurable way. Authentication and authorization can be configured via config files. Installation ============ The preferred manner of setup is to install ClueBzrServer within a virtualenv_. Older instructions for setting up virtualenv can be found at `Setting up virtualenv`_. Once the virtualenv is setup just use ``easy_install`` in the traditional way. For example:: $ easy_install ClueBzrServer Usage ===== Running the Server ------------------ Once ClueBzrServer is installed, running ``clue-bzrserver`` the first time will generate a standard config file with all access turned off (for security reasons). This will serve the currect directory as a bzr source:: $ clue-bzrserver To specify an alternate port to the default 8080, try:: $ clue-bzrserver -p 9339 Display the ``--help`` arg for usage info:: $ clue-bzrserver --help The default configuration will be generated at ``clue-bzrserver.ini`` in the same directory. It is configured to use htpasswd based access by looking at the file ``clue-bzrserver.passwd`` in the same directory. Use the standard apache2 ``htpasswd`` tool to update username/password entries. At this point you should setup your first user account by doing something like follows (assumes apache2 ``htpasswd`` utility is available somewhere on the path):: $ htpasswd clue-bzrserver.passwd testuser1 The complete format of ``clue-bzrserver.ini`` for allowing access such as SQL or LDAP is dictated by the repoze.who_ project. See `repoze.who security`_ for details. ACL Security ------------ Security can be defined on a per branch basis. It gets defined inside the ``clue-bzrserver.ini`` file. Here's an example:: [authz:MyProject/trunk] anonymous = r testuser1 = rw Connecting to the Server ------------------------ After you have launched the server for the first time the simplest way to get started is as follows:: $ bzr init-repo --no-trees --1.9 bzr+http://testuser1:mypassword@localhost:8080/MyProject Now go ahead and start your new project (or work within an existing non-versioned directory). Lets assume you're working on a project called "MyProject" and now want to turn what you have into the trunk:: $ cd MyProject $ bzr init $ bzr push --create-prefix bzr+http://testuser1:mypassword@localhost:8080/MyProject/trunk Once you make some changes, you commit then as you normally would:: $ bzr commit And then you have to make sure to push your local commits to the parent branch which in this case is the remote trunk:: $ bzr push License ======= ClueBzrServer is covered under a BSD license. See ``LICENSE.txt`` for further details. Credits ======= Written and maintained by Rocky Burt (rocky AT serverzen DOT com). .. _virtualenv: http://pypi.python.org/pypi/virtualenv .. _repoze.who: http://pypi.python.org/pypi/repoze.who/ .. _`repoze.who security`: http://static.repoze.org/whodocs/narr.html#middleware-configuration-via-config-file .. _`Setting up virtualenv`: http://neuroimaging.scipy.org/site/doc/manual/html/devel/tools/virtualenv-tutor.html .. -*-rst-*- Changelog ========= 0.2 - (Mar-01-2009) ------------------- * New ACL based security 0.1 - Nov-10-2008 ----------------- * Initial release vudo.skinsetup 0.1 Package which provides API and scripts to manage a skin directory of a VUDO app. Stefan Eletzhofer Introduction ============ This package provides an light-weight API for ``vudo`` packages which provide user-changeable skins. These packages may advertise their skin directory using ``setuptools entry points``. Additionally, this package provides a script to manage the skin directory of a ``vudo`` project in a convenient way. Usage ===== Developers, which want to make ``vudo`` packages which provide skins, need to include their skin resources in the EGG, and include a entry point. Skin Resources -------------- Depending whether or not a SCM system supported by setuptools (currently SVN) is used or not, developers may need to include their resources manually using ``package_data``:: setup(name='vudo.compositepage', ... packages=find_packages('src'), package_dir = {'': 'src'}, package_data = { "vudo.compositepage": [ "skin/*.zcml", "skin/compositepage/*.zcml", "skin/compositepage/ajax/*.pt", "skin/region/*.pt", ] }, ... ) Entry Point ----------- Additionally to include the skin resources in the package egg, the skin needs to be advertized using a ``entry point``:: setup(name='vudo.compositepage', ... entry_points=""" # -*- Entry points: -*- [vudo.skin] compositepage=vudo.compositepage:provide_skin [skin] """, extras_require={ "skin": "vudo.skinsetup", }, ... ) The ``provide_skin`` mentioned above needs to call the ``vudo.skinsetup`` package API to return the skin information:: def provide_skin(): import os from vudo.skinsetup import provide_skin return provide_skin( package="vudo.compositepage", name="compositepage", skin_path="skin") the parameters to the ``provide_skin`` method are as follows: package The package name which provides the skin name The skin name skin_path The ``path`` to the skin within the package. Note, this is usually a ``setuptools`` resource path, and thus always "/" separated. Do not use ``os.path``. Links ===== Pkg resources and Entry Points http://peak.telecommunity.com/DevCenter/PkgResources#entry-points http://peak.telecommunity.com/DevCenter/PkgResources#resourcemanager-api Quick tutorial http://wiki.pylonshq.com/display/pylonscookbook/Using+Entry+Points+to+Write+Plugins Change history ============== Changelog ========= 0.1 (2008-12-08) ---------------- - Script entry point for ``vudoskin`` script. [seletz] - Very basic API for vudo packages which want to provide a skin [seletz] - Initial package setup. [seletz] Contributors ============ Stefan Eletzhofer, Author Download ======== repoze.tm 1.0a5 Zope-like transaction manager via WSGI middleware Agendaless Consulting repoze.tm (Transaction Manager) =============================== Middleware which uses the ZODB transaction manager to wrap a call to its pipeline children inside a transaction. See docs/index.rst for documentation. mrgit.web 0.1 mrgit.web Rok Garbas Introduction ============ 0.1 Initial version repoze.filesafe 1.0a6 Transaction-aware file creation Wichert Akkerman repoze.filesafe =============== repoze.filesafe provides utilities methods to handle creation of files on the filesystem safely by integrating with the ZODB package's transaction manager. It can be used in combination with repoze.tm (or repoze.tm2) for use in WSGI environments. See docs/index.rst for documentation. 1.0a6 ----- - Fix packaging error. [wichert] 1.0a5 ----- - Add a MockFile class to help with handling of files when using the DummyDataManager. [fschulze] 1.0a4 ----- - Add a new openFile method to facilitate opening of files that have not been commited yet. [wichert] 1.0a3 ----- - Add method to facilitate unit testing of code using repoze.filesafe. [wichert] 1.0a2 ----- - Add support for Python 2.4 and 2.5. [wichert] 1.0a1 ----- - Initial Release repoze.bfg.skins 0.20 Skin support for BFG. UNKNOWN Overview ======== .. role:: mod(emphasis) .. role:: term(emphasis) This package provides a simple framework to integrate code with templates and resources. See full documentation at: http://packages.python.org/repoze.bfg.skins/. About ----- The package is written and maintained by `Malthe Borch <mailto:mborch@gmail.com>`_ and `Stefan Eletzhofer <stefan.eletzhofer@inquant.de>`_. Available as-is under the BSD license. To contribute or get support for this package, please visit the #repoze channel on freenode irc or write to the `repoze-dev mailinglist <repoze-dev@lists.repoze.org>`_. Changelog ========= 0.20 (2009-12-14) - Compatibility fixes for BFG 1.2. 0.19 (2009-11-27) - Use the ``MacFSEvents`` module instead of ``pyfsevents``. 0.18 (2009-11-26) - Added discovery support (Mac OS X and Linux). - Allow hyphens in the skin expression translator. - Do not set charset on binary responses. - Add content length to static responses. 0.17 (2009-11-16) - Skin objects used as descriptors now pass on the class instance dict as the keyword argument dictionary. - Skin templates may now be used as macros. - Make sure expression syntax is correct. 0.16 (2009-11-14) - Acquisition-like skin object lookup from within templates, e.g. ``skin: main_template`` will try to acquire the object from the current skin object path (if applicable), while ``skin: /main_template`` will always use an absolute (direct) lookup. 0.15 (2009-11-12) - Make ``name`` attribute public. - Normalize path (ZCML does this, but we might be used imperatively). - Raise runtime-error if view is attempted registered for unknown skin object (should never happen, but did because of an internal bug). 0.14 (2009-11-09) - Look up skin object on call if object has not been resolved. - Added index view registration option. - Use ``Chameleon`` egg. - Pin package versions for testing. 0.13 (2009-10-30) - Rewrite. Backwards-compatibility broken. Migration path: Skins registrartion directive renamed to <bfg:skins>. To register views for skin objects, the <bfg:view> directive should be used inside a <bfg:skins> declaration. See documentation. Previous users should consult documentation for more information. - Made compatible with repoze.bfg 1.1a4. - Disuse ``component.adapts`` (unuseable in any BFG app), to make compatible with repoze.bfg 1.1a6+. 0.12 (2009-02-12) - Added convenience method ``get_skin_template_view``. [malthe] - The ``get_skin_template`` method now accepts an optional ``request_type`` parameter, which takes priority in adaptation. [malthe] - The ``provides`` parameter has been retired; instead, a ``class`` parameter may be provided. By default this is set to the ``SkinTemplate`` class; to register a view, simply set it to ``SkinTemplateView`` (full module path required). [malthe] 0.11 (2009-02-09) - View permission is now only registered if a view must be provided. [malthe] - Multiple interfaces may be specified as ``provides``. [malthe] 0.10 (2009-01-28) - Added parameter ``content_type`` which will set the content type of the view response. [malthe] - Added ``macros`` attribute to the template object. [malthe] 0.9 (2008-12-05) - Updated signatures for skin template factory lookup functions. [malthe] - Added support for skin api methods. [malthe] 0.8 (2008-12-05) - Provide ``ISkinMacro`` unless ``provides`` is set; however, always provide ``ISkinTemplate``. Meanwhile, the macro accessor looks only for skin templates registered for the ``ISkinMacro`` interface. [malthe] 0.7 (2008-12-04) - If ``provides`` is set, do not automatically provide the ``ISkinTemplate`` interface as well; this behavior made it difficult to program cascading rendering schemes. [malthe] - Keyword-arguments are now accepted by the utility methods for rendering skin templates using Python. [malthe] - Added security assertions to macro rendering function to prevent infinite loop if a template tries to render itself. [malthe] 0.6 (2008-12-03) - Do not register macro components separately, but make them available from the ``macro`` attribute of a skin template. [malthe] 0.5 (2008-12-03) - Added component lookup scheme for the bound skin template object which makes skin API components available using ``get_<name>`` where <name> is the component name. [malthe] - Restructured package and changed look up scheme for skin APIs and macros. A symbol ``template`` is now available to skin templates; from this object, methods ``get_api`` and ``get_macro`` can be used to look up skin APIs and macros, respectively. [malthe] - Added render_skin_template_to_response and render_skin_template methods for general template rendering. [fairwinds] 0.4 (2008-11-13) - Added ``name`` attribute to skin template interface. [malthe] - No longer provide ``repoze.bfg.interfaces.IView`` by default; the ``provides`` attribute may now be used to specify an additional interface which the skin templates will provide. [malthe] 0.3 (2008-10-29) - Fix performance issue where template objects would be instantiated at every call. [malthe] - Pass keyword arguments to skin template callable. [malthe] - Instantiate page template directly. [malthe] 0.2 (2008-10-03) - Templates located in subdirectories are now named by replacing the operating system path separator with a forward slash symbol (often this will be the same character); before a dot '.' was used. [malthe] - Added Template API base class. [malthe] - Renamed ``IApi`` to ``ITemplateAPI``. [malthe] - Template API components should adapt (context, request, template), where ``template`` is the skin template object (such an API might need to provide access to the template file itself, in order to get a path to resources local to the template). [malthe] - Added ``render`` method to skin template class to allow rendering to a string instead of to a WebOb response. [malthe] - Renamed package to ``repoze.bfg.skins`` [seletz] - Added logic to allow registering and acquiring template API components from templates. [malthe] - Changed the Skin Template View to be a class, and added a minimal interface ISkinTemplate to access the template path [seletz] - Fixed a bug where we did not tear down the tests correctly [seletz] - Fixed bug where the INewRequest event handler would call templates when checking for their existence [seletz] 0.1 (2008-09-25) - Initial release [malthe] - Added support to dynamically register templates if they are added to a registered template directory [seletz] repoze-oauth-plugin 0.2 OAuth plugin for repoze.who and repoze.what Linas Juškevičius repoze-oauth-plugin =================== repoze-oauth-plugin is a repoze.who_ and repoze.what_ plugin implementing the server side of the `OAuth 1.0`_ protocol. It supports both: * 2-legged flow where the client is at the same time a resource owner and * 3-legged flow where the client acts on behalf of a resource owner. You can read more about OAuth at hueniverse_. Installation ------------ easy_install_:: $ <env>/bin/easy_install repoze-oauth-plugin pip_:: $ <env>/bin/pip install repoze-oauth-plugin Documentation ------------- The documentation can be found at packages.python.org_. Source ------ The source code repository can be found at GitHub_. .. _repoze.who: http://static.repoze.org/whodocs/ .. _repoze.what: http://what.repoze.org/docs/1.0/ .. _OAuth 1.0: http://oauth.net/core/1.0a/ .. _hueniverse: http://hueniverse.com/oauth/ .. _2-legged flow: http://hueniverse.com/oauth/guide/terminology/ .. _GitHub: http://github.com/kaukas/repoze-oauth-plugin .. _easy_install: http://peak.telecommunity.com/DevCenter/EasyInstall .. _pip: http://pip.openplans.org/ .. _packages.python.org: http://packages.python.org/repoze-oauth-plugin/ repoze.what.plugins.couchdbkit 0.2 repoze.what plugin for couchdbkit Gael Pasgrimaud Full documentation can be found `here <http://www.gawel.org/docs/repoze.what.plugins.couchdbkit/index.html>`_ Report bugs on the `bitbucket tracker <http://bitbucket.org/gawel/repoze.what.plugins.couchdbkit/issues/>`_ repoze.what-pylons 1.0 The repoze.what v1 plugin for Pylons/TG2 integration Gustavo Narea ********************************************* The repoze.what plugin for Pylons integration ********************************************* This is an extras plugin for repoze.what which provides optional and handy utilities for Pylons applications using this authorization framework. Some of the features of the plugin include: * The utilities are ready to use: There's nothing additional to be configured before using. * 100% documented. Each component is documented along with code samples. * The test suite has a coverage of 100% and it will never decrease -- if it ever does, report it as a bug! * TurboGears 2 is officially supported as well. repoze.component 0.4 A Python component system Agendaless Consulting repoze.component README ======================= ``repoze.component`` is a package that software developers can use to provide configurability and pluggability to their applications. ``repoze.component`` provides a generalized indirection mechanism which can be used to provide plugin points to integrators or other developers who may wish to provide alternate implementations of application logic or configuration values. See docs/index.rst or `http://docs.repoze.org/component <http://docs.repoze.org/component>`_ for more information. repoze.component Changelog ========================== 0.4 (2009-07-25) ---------------- - Make compatible with repoze.component 0.4. - Add ``override`` keys to ``component`` and ``subscriber`` directives. 0.3 (2009-07-24) ---------------- - Update directive implementations to match newer repoze.component calling conventions. - Provide a ``full`` argument to the ``clear`` method of ``repoze.component.registry.Registry`` which clears the registry entirely instead of just clearing unnamed registrations. It defaults to false. 0.2 (2009-07-11) ---------------- - Break apart component type storage into ``__component_types__`` and ``__inherited_component_types__`` attributes. The ``__component_types__`` attribute has become a sequence of component types stored directly on an instance as a result of ``provides(ob, 'sometype')``. The ``__inherited_component_types__`` attribute is stored on a class as the result of ``provides(cls, 'sometype')`` ( or via a class-level call to ``provides('a', 'b')`` ). We then recompose these two separate attributes into a unified set of component types when the ``resolve`` method of the registry is called to create an effective list of component types. - ``repoze.component.directlyprovidedby`` now returns only the types directly provided by an instance (its ``__component_types__``); previously it would also return the inherited component types (because there was no such thing as an inherited component type). However, ``repoze.component.providedby`` continues to return all component types (both direct and inherited, as well as default types). - Add ``onlyprovides`` API, which overwrites any existing ``__component_types__`` (or ``__inherited_component_types__``) attribute on the object. It otherwise acts just like ``provides``. 0.1 (2009-06-22) ---------------- - Initial release. repoze.bfg.httprequest 0.4.2 Adaptable request interfaces. Malthe Borch and Stefan Eletzhofer Overview ======== The motivation for this package is to encourage the use of request type adaptation instead of depending on packages with request type definitions. Instead of subclassing the request interface, we encourage an adaptation pattern: >>> from repoze.bfg.interfaces import IRequest >>> IGZipRequest = IRequest({'http_accept_encoding': 'gzip'}) An event handler listens for the ``INewRequest`` event and automatically marks the request with interfaces as needed to adapt the request to the request types that it may apply for. To complete the example above, a request would come in with an HTTP environment like the following: {'http_accept_encoding': 'compress, gzip'} Since we've previouly adapted the request to an accept-encoding of 'gzip', the adaptation machinery will mark the interface such that this environment will match the ``IGZipRequest`` interface. This would be an alternative to subclassing, where we would manually have to set up an event listener that interprets the request environment and marks the request with the interface. >>> class IGZipRequest(IRequest): ... """Marker interface for requests for gzipped response.""" Credits ------- Stefan Eletzhofer <stefan.eletzhofer@inquant.de> and Malthe Borch <mborch@gmail.com>. Adaptable HTTP request interfaces ================================= Suppose we want to adapt on requests that have an "http_accept_encoding" that calls for a gzipped response, we'd set up an interface as follows: >>> from repoze.bfg.interfaces import IRequest >>> IGZipRequest = IRequest({'http_accept_encoding': 'gzip'}) Let's now craft a request that will match this interface. >>> class TestRequest(object): ... interface.implements(IRequest) ... ... def __init__(self, environ): ... self.environ = environ >>> request = TestRequest({'http_accept_encoding': 'compress, gzip'}) At this point, the request has not been prepared for adaptation. >>> from repoze.bfg.events import NewRequest >>> from zope.event import notify >>> notify(NewRequest(request)) We expect the request to implement the ``IGZipRequest`` interface. >>> IGZipRequest.providedBy(request) True To get more flexibility, we can supply a match function: >>> IAlternativeGZipRequest = IRequest( ... {'http_accept_encoding': lambda value: 'gzip' in value}) >>> notify(NewRequest(request)) >>> IAlternativeGZipRequest.providedBy(request) True Suppose now we'd also like to support requests for documents in German. >>> IGermanLanguageRequest = IRequest({'http_accept_language': 'de'}) We'll create a new request, which, besides asking a gzipped response, also asks for the content in German. >>> request = TestRequest( ... {'http_accept_encoding': 'compress, gzip', 'http_accept_language': 'de'}) >>> notify(NewRequest(request)) Verify that the request provides the adapted interfaces. >>> IGermanLanguageRequest.providedBy(request) True >>> IGZipRequest.providedBy(request) True Now, as you would expect, we can adapt a request interface that combines these two environments. >>> IZippedGerman = IRequest( ... {'http_accept_encoding': 'gzip', 'http_accept_language': 'de'}) >>> notify(NewRequest(request)) >>> IZippedGerman.providedBy(request) True Note that this interface extends the two interfaces that were created for each of the environment pairs of it. >>> IZippedGerman.isOrExtends(IGermanLanguageRequest) True >>> IZippedGerman.isOrExtends(IGZipRequest) True Let's try a request that doesn't match. >>> IZippedFrench = IRequest( ... {'http_accept_encoding': 'gzip', 'http_accept_language': 'fr'}) >>> notify(NewRequest(request)) >>> IZippedFrench.providedBy(request) False Adapted requests are global with respect to the environment: >>> IRequest({'http_accept_encoding': 'gzip'}) is IRequest({'http_accept_encoding': 'gzip'}) True Pickle-support -------------- The adapted interface are created dynamically and would therefore not be locatable by the ``pickle`` module. To remedy this, an import hook is added on package initialization. (The ``repoze.bfg`` packages pickles configuration actions in order to improve startup time, and therefore it's important that the adapted interfaces are pickable.) >>> from pickle import dumps, loads >>> p = dumps(IGZipRequest) Now, we'll pretend that we the ``repoze.bfg.httprequest.interfaces`` has not yet been imported. This will make pickle import it when we load back the pickle. >>> import sys >>> del sys.modules['repozehttprequestinterfaces'] We'll reinitialize the interfaces module. >>> loads(p) <IHTTPRequest http_accept_encoding=gzip> repoze.who.plugins.ldap 1.1a1 LDAP plugin for repoze.who Gustavo Narea repoze.who.plugins.ldap -- LDAP Authentication for WSGI Applications repoze.who.plugins.ldap is an LDAP plugin for the identification and authentication framework for WSGI applications, repoze.who, which acts as WSGI middleware. It provides you with an straightforward solution to enable LDAP support in your applications. Yes, you read well: "straightforward", "LDAP" and "applications" are in the same sentence. In fact, you may make your application LDAP-aware in few minutes and with few lines of code. Another great news is that this package is *fully* documented and provides you with a working and documented demo project. See the `docs` subdirectory of this package for more information, or browse the online documentation <http://code.gustavonarea.net/repoze.who.plugins.ldap/>. repoze.who.plugins.ldap Changelog ================================= 1.1 Alpha 1 (2010-01-03) ------------------------ - Changed the license to the `Repoze license <http://repoze.org/license.html>`_. - Provided ``start_tls`` option both for the authenticator and the metadata provider. - Enable both pattern-replacement and subtree searches for the naming attribute in ``_get_dn()``. - Enable configuration of the naming attribute - Enable the option to bind to the server with privileged credential before doing searches - Add a restrict pattern to pre-authentication DN searches - Let the user choose whether to return the full DN or the supplied login as the user identifier 1.0 (2008-09-11) ---------------- The initial release. - Provided the LDAP authenticator, which is compatible with identifiers that define the 'login' item in the identity dict. - Included the plugin to load metadata about the authenticated user from the LDAP server. - Documented how to install and use the plugins. - Included Turbogears 2 demo project, using the plugin. There is also a section in the documentation to explain how the demo works. repoze.timeago 0.5 Compute human-friendly elapsed time messages Agendaless Consulting ``repoze.timeago`` README ========================= This package provides library function for rendering a human-friendly message describing elapsed time since an event. ``repoze.timeago`` Changelog ============================ 0.5 (2010-07-13) ---------------- - Initial public release. -
python.templating.engines
Package Name Version Summary Author Description TurboCheetah 1.0 TurboGears plugin to support use of Cheetah templates Kevin Dangoor et al This package provides a template engine plugin, allowing you to easily use Cheetah with TurboGears, Buffet or other systems that support python.templating.engines. genshicolumntemplate 0.2 Adds a 3 column layout to the genshi quickstart template for Turbogears. Linden Wright 3 column layout is based on the A List Apart 'Holy Grail' article by Matthew Levine, found at (http://www.alistapart.com/articles/holygrail/). This template requires that the genshi quickstart template by Fred Lin is installed. GHRML 0.11 GHRML - Haml for Genshi Richard Davies UNKNOWN Genshi 0.6 A toolkit for generation of output for the web Edgewall Software Genshi is a Python library that provides an integrated set of components for parsing, generating, and processing HTML, XML or other textual content for output generation on the web. The major feature is a template language, which is heavily inspired by Kid. TurboJinja 0.9.1 Jinja(Django & Smarty-like) template for TurboGears Fred Lin Jinja (Django & Smarty-like) template for TurboGears, Install ----------- You can install turbojinja with setuptools $ easy_install jinja $ easy_install turbojinja ChangeLog ---- 0.9.1 - support template inheritance, thanks Robin TurboKid 1.0.5 Python template plugin that supports Kid templates Kevin Dangoor et al This package provides a template engine plugin, allowing you to easily use Kid with TurboGears, Buffet or other systems that support python.templating.engines. TurboDjango 0.95w2 Django template for TurboGears, need Django to work Fred Lin Lots of people use Django template for Pyhton Web Framework(As Django project shares). Now you can comfortably try TurboGears with Django template. This template plugin can be used with TurboGears or Buffet. http://docs.turbogears.org/1.0/DjangoTemplating Breve 1.3.0 An s-expression style template engine. Cliff Wells Breve is a Python template engine that is designed to be clean and elegant with minimal syntax. Unlike most Python template engines, Breve is implemented as an `internal DSL`_ rather than a parser. Breve was heavily inspired by `Nevow Stan`_ and is, in fact, the successor to TurboStan_, my earlier attempt to bring a Stan-like engine to TurboGears. Breve supports the Buffet_ template engine API which means it works automatically with several frameworks, including Pylons_, CherryPy_ and TurboGears_. Breve also supports Django_. .. _Nevow Stan: http://divmod.org/trac/wiki/DivmodNevow .. _Buffet: http://projects.dowski.com/projects/buffet .. _TurboGears: http://www.turbogears.org .. _Pylons: http://www.pylonshq.com .. _CherryPy: http://www.cherrypy.org .. _TurboStan: http://www.develix.com/software .. _Django: http://www.djangoproject.com .. _`internal DSL`: http://martinfowler.com/bliki/DomainSpecificLanguage.html Jinja 1.2 A small but fast and easy to use stand-alone template engine written in pure python. Armin Ronacher jinja ~~~~~ Jinja is a `sandboxed`_ template engine written in pure Python. It provides a `Django`_ like non-XML syntax and compiles templates into executable python code. It's basically a combination of Django templates and python code. Nutshell -------- Here a small example of a Jinja template:: {% extends 'base.html' %} {% block title %}Memberlist{% endblock %} {% block content %} <ul> {% for user in users %} <li><a href="{{ user.url|e }}">{{ user.username|e }}</a></li> {% endfor %} </ul> {% endblock %} Philosophy ---------- Application logic is for the controller but don't try to make the life for the template designer too hard by giving him too few functionality. For more informations visit the new `jinja webpage`_ and `documentation`_. Note ---- This is the Jinja 1.0 release which is completely incompatible with the old "pre 1.0" branch. The old branch will still receive security updates and bugfixes but the 1.0 branch will be the only version that receives support. If you have an application that uses Jinja 0.9 and won't be updated in the near future the best idea is to ship a Jinja 0.9 checkout together with the application. The `Jinja tip`_ is installable via `easy_install` with ``easy_install Jinja==dev``. .. _sandboxed: http://en.wikipedia.org/wiki/Sandbox_(computer_security) .. _Django: http://www.djangoproject.com/ .. _jinja webpage: http://jinja.pocoo.org/ .. _documentation: http://jinja.pocoo.org/documentation/index.html .. _Jinja tip: http://dev.pocoo.org/hg/jinja-main/archive/tip.tar.gz#egg=Jinja-dev :copyright: 2007 by Armin Ronacher. :license: BSD, see LICENSE for more details. -
pylons
Package Name Version Summary Author Description Tesla 0.2.6 Pylons template with Elixir ORM bindings beachcoder Tesla ====== Tesla is a web framework built on Pylons/Paste and Elixir/SQLAlchemy. It includes paster commands for database management, migrations, and model scaffolding, plus AuthKit integration. With just a little bit of glue Tesla gives you the best Python web development libraries around today. Current Status --------------- Tesla 0.2.6 described on this page is stable. There is also an unstable `development version <http://tesla-pylons-elixir.googlecode.com/svn/trunk/#egg=Tesla-dev>`_ of Tesla. Download and Installation ------------------------- Tesla can be installed with `Easy Install <http://peak.telecommunity.com/DevCenter/EasyInstall>`_ by typing:: > easy_install Tesla More information ---------------- Check out the project home page on `Google Code <http://code.google.com/p/tesla-pylons-elixir/>`_. PyISAPIe 1.1.0-rc4 1.1.0 Release Candidate 3: Python ISAPI extension for IIS with Django, WSGI, and Trac support Phillip Sitbon PyISAPIe is a high-performance (much much faster than FastCGI) ISAPI extension for interpreting Python scripts in a Windows web server environment such as IIS or Apache. Includes WSGI support and Django handler support. Tested and working with Trac 0.10. Also tested and working with Paste/Pylons. SimpleSite 0.3.0 A simple website application written as a demonstration of Pylons for the Definitive Guide to Pylons James Gardner ++++++++++ SimpleSite ++++++++++ A simple website application allowing WYSIWYG editing, sections and subsections and full navigation widgets. The idea is that the application can form a starting point for your own website projects. Installation ============ First install Easy Install if you don't have it already by downloading ``ez_setup.py`` from http://peak.telecommunity.com/dist/ez_setup.py and installing it like this:: python ez_setup.py Install SimpleSite like this specifying either MySQL, SQLite or PostgreSQL as the word within the square brackets depending on the database you intend to use:: easy_install SimpleSite["MySQL"] paster make-config simplesite.ini Configure the application by editing ``simplesite.ini`` to specify a database to use using the format described at http://www.sqlalchemy.org/docs/05/dbengine.html#dbengine_supported :: paster setup-app simplesite.ini paster serve simplesite.ini The running application will now be available at http://localhost/ Files ===== mapfish 1.2.2 The MapFish web-mapping framework. Camptocamp MapFish ======= MapFish is a Pylons-based web framework with GIS orientations. MapFish provides: * a geometry type which is to be used when mapping PostGIS tables with SQLAlchemy * a paster command to generate model and controller mode corresponding to layers (PostGIS tables) defined in a configuration file * an implementation of a RESTful protocols for creating, reading, updating, and deleting geographic objects (features) MapFish relies on the geojson and shapely packages, see http://gispython.org. MapFish projects are Pylons projects, the project developer therefore fully benefits from the power of Pylons and its companion components (SQLAlchemy, Mako, etc.). Current status -------------- MapFish 1.2.2 described in this page is the current stable version. Download and Installation ------------------------- MapFish can be installed with `Easy Install <http://peak.telecommunity.com/DevCenter/EasyInstall>`_ by typing:: > easy_install mapfish BlastOff 0.2 A Pylons application template providing a working site skeleton configured with SQLAlchemy, mako, repoze.who, ToscaWidgets, TurboMail, WebFlash and (optionally) SchemaBot. The generated app is pre-configured with authentication, login and registration forms, and (optionally) email confirmation. Chris Miles BlastOff helps accelerate Pylons application development by generating a project with a number of pre-configured dependencies. Installation ------------ Use pip:: $ pip install BlastOff or use setuptools:: $ easy_install BlastOff or old school, download the package from http://pypi.python.org/pypi/BlastOff, unpack it and run (as root if required):: $ python setup.py install Usage ----- Create a new Pylons project from the BlastOff template with:: $ paster create -t blastoff AppName You will be prompted for a few options. 1. SQLAlchemy database URL:: Enter sqlalchemy_url (The SQLAlchemy URL of the database) ['sqlite:///%(here)s/development.db']: Specify the database URL that will be used by SQLAlchemy. Defaults to an SQLite database. For PostgreSQL use something like:: postgres://user:pass@hostname/dbname 2. SchemaBot database schema version control:: Enter use_schemabot (Enable database schema version control using SchemaBot) [True]: If True then SchemaBot will be used to automatically manage the SQLAlchemy database schema. 3. Email confirmation to activate new user accounts:: Enter email_confirmation (True/False: New users must click activation link from confirmation email) [True]: If True the application will be configured to send a confirmation email to the user upon registration. The email will contain a link for activating the account before it can be used. If False no activation confirmation will be configured so users will be able to login immediately after registering. 4. Create a default user:: Enter default_user (Default username to create, password will match username (leave blank for no default user)) ['']: To have a default user created when the database is set up enter the username here. After creation the Pylons app is ready to be used. To ensure all the application dependencies are installed you can run this command from the application directory:: $ python setup.py develop Before starting the app the database needs to be set up (i.e. tables created). This is done by using the standard Pylons command:: $ paster setup-app development.ini If the SchemaBot option was enabled then a BlastOff generated project will use SchemaBot to manage database schema changes. The initial tables will be created by SchemaBot, the default user inserted if that option was selected, and the database marked as schema version 1. See model/__init__.py within the application source for more information. To run the application use the standard Pylons command:: $ paster serve --reload development.ini Point your browser at the URL http://127.0.0.1:5000/ The generated project contains model and functional tests that can be run using the "nosetests" command (requires the Nose package to be installed). Documentation ------------- For more information see the BlastOff wiki at http://bitbucket.org/chrismiles/blastoff/wiki/Home or the Pylons documentation at http://pylonshq.com/ Shabti 0.3.2c Pylons template with Elixir ORM bindings Graham Higgins Shabti ====== Shabti is a set of Pylons kick-start services built on Pylons/Paste and, variously Elixir, SQLAlchemy, rdflib, RDFAlchemy. It includes paster commands for database management, migrations and model scaffolding, plus AuthKit integration. With just a little bit of glue Shabti gives you a major kick-start using the best Python web development libraries around today. Current Status --------------- Shabti 0.3.2c described on this page is stable. There is also an unstable `development version <http://www.bitbucket.org/gjhiggins/shabti/overview/>`_ of Shabti. Download and Installation ------------------------- Shabti can be installed with `Easy Install <http://peak.telecommunity.com/DevCenter/EasyInstall>`_ by typing:: > easy_install Shabti More information ---------------- Check out the project home pages on `BitBucket <http://www.bitbucket.org/gjhiggins/shabti/overview/>`_ and `Bel-EPA <http://bel-epa.com/shabtidocs/>`_ SimpleSiteTemplate 0.1 A Paste Template which allows you to create a new Pylons project based on the SimpleSite tutorial described in the Pylons Book James Gardner UNKNOWN Agatsuma 0.1.108.master.e997a96fe9f66e5066706ce6947db715b1b0b6dc Flexible modular metaframework, mostly intended for web but not only Fei Wong Reed UNKNOWN Restin 0.1a0dev-r21 RESTful admin app for Pylons Wyatt L Baldwin, byCycle.org UNKNOWN mongokit-pylons 0.2.0 MongoDB interface for ORM-like object mapping (w/ Pylons support) Brendan W. McAdams ========================= This package is DEPRECATED ========================= All of the changes in this package have been merged back into the original project, MongoKit ... As a result, it makes the most sense to deprecate mongokit-pylons. MongoKit has, since the merge, added a large body of additional functionality. I am working on a bridge version to assist with migration, but for now you should look towards moving over to the main project. ========================= What is MongoDB/MongoKit? ========================= MongoDB is a free & open source, schemaless document oriented database (available at http://mongodb.org). The MongoKit framework is an ORM-like layer which provides an enhanced approach to managing your MongoDB data by providing an object layer. This layer allows you to define rough schema outlines including default values and allowed & required fields. While schemaless databases have power in their lack of schema, it helps to control what fields are and aren't permitted (even if you only use 3 of 10 most times) to ensure consistency. The original MongoKit is written by Namlook, and is available at http://bitbucket.org/namlook/mongokit/ MongoKit-Pylons is a (hopefully temporary) fork which provides a toolset for easily integrating MongoKit within the Pylons web framework. It provides the ability to parse mongo configuration from Pylons ini config files, and setup easily in config/environment.py as an always-available, threadlocal connection pool (similar to how SQLAlchemy is typically setup in Pylons). From my own usage of MongoKit following integrating Pylons support into my production systems, I have added several enhancements to the MongoKit-Pylons fork which I've found useful. These features include property-like setter/getter proxying for values (instead of pure dictionary access) and support for the MongoDB driver's autoreferencing features. Autoreferencing allows you to embed MongoKit objects/instances inside another MongoKit object. With autoreferencing enabled, MongoKit and the pymongo driver will translate the embedded MongoKit object values into internal MongoDB DBRefs. The (de)serialization is handled automatically by the pymongo driver. It is my hope/intention to merge this fork back into the main project. =============== MongoKit-Pylons =============== [Note that if you used an earlier version of this fork, I have recently changed the namespace to mongokit.pylons so as not to conflict. The latest release can be grabbed from pypi] .. _release: http://pypi.python.org/pypi/mongokit-pylons .. _pypi: http://pypi.python.org/pypi/mongokit-pylons This is a fork (hopefully temporary, as I'd like to merge into one codebase) of the fantastic MongoKit_ to add better support for Pylons_. Along the way I have added a few features such as __setattr__ / __getattr__ to set / get values as properties rather than talking to the dictionary. This fork also supports the autoreferencing feature from the pymongo_. driver. MongoPylonsEnv is a helper class for using MongoKit_ inside of Pylons_. - The recommended deployment is to add a call to init_mongo() in config/environment.py for your pylons project. Like with SQLAlchemy_, this will setup your connections at Pylons boot; the MongoDB_ Pool code should ensure you have enough connections. .. _MongoKit: http://bitbucket.org/namlook/mongokit/wiki/Home .. _Pylons: http://pylonshq.com .. _SQLAlchemy: http://sqlalchemy.org .. _pymongo: http://github.com/mongodb/mongo-python-driver/ .. _autoref_sample: http://github.com/mongodb/mongo-python- driver/blob/cd47b2475c5fe567e98696e6bc5af3c402891d12/examples/auto_r eference.py Add the import at the top:: >>> from mongokit.pylons.pylons_env import MongoPylonsEnv And lower down, in load_environment():: >>> MongoPylonsEnv.init_mongo() Additionally, you'll need to add several items to your configuration ini file:: >>> # Mongo Database settings ... mongodb.host = localhost ... mongodb.port = 27017 ... mongodb.db = your_db_name ... mongodb.connection_timeout = 30 ... mongodb.pool.enable = True ... mongodb.pool.size = 20 To enable pylons support, your document class MUST specify:: >>> _use_pylons = True as a class level attribute. MongoKit's document connection management is class based, so if you need the same document to work in and out of pylons, it is recommended you create a "normal" MongoDocument subclass, and a subclass of THAT which defines _use_pylons. Alternately, for the ultimate in lazy:: >>> from mongokit.pylons.document import MongoPylonsDocument And then subclass from that (It's a proxy subclass of MongoDocument which enables use_pylons). One further perk of this version is AutoReferences. Autoreferences allow you to pass other MongoDocuments as values. pymongo_. (with help from MongoKit) automatically translates these object values into DBRefs before persisting to Mongo. When fetching, it translates them back, so that you have the data values for your referenced object. See the autoref_sample_. for further details/internals on this driver-level functionality. As for enabling it in your own MongoKit code, simply define the following class attribute upon your Document subclass:: >>> _enable_autoref = True With autoref enabled, MongoKit's connection management will attach the appropriate BSON manipulators to your document's connection handles. We require you to explicitly enable autoref for two reasons: - Using autoref and it's BSON manipulators (As well as DBRefs) come with a performance penalty, so we don't load them unless you opt-in at class-level. - You may not wish to use auto-referencing in some cases where you're using DBRefs. Once you have autoref enabled, MongoKit will allow you to define any valid subclass of MongoDocument as part of your document structure. **If your class does not define _enable_autoref as True, MongoKit's structure validation code will REJECT your structure. The rules are *autoref enabled*, *issubclass(<type>, MongoDocument)*.** A detailed example:: >>> class BlogEntry(MongoPylonsDocument): ... collection_name = 'blog' ... structure = { ... 'author': AdminUser, ... 'publish_date': datetime.datetime, ... 'title': unicode, ... 'entry': unicode, ... } ... ... _enable_autoref = True ... required_fields = ['author', 'publish_date', 'entry', 'title'] ... default_values = {'publish_date': datetime.datetime.now()} Additionally, with this codebase, MongoDocument supports property style set/get. Where in the original codebase you had to do:: >>> user = TestUserDocument() ... user['password'] = 'p455' With this code you can invoke it as:: >>> user = TestUserDocument() ... user.password = 'p455' For any questions related to this fork, especially the Pylons & Autoref (and properties) support, please contact myself (Brendan McAdams ) rather than namlook. I can be reached at NO*bwmcadams*SPAM@gmail.*OMGSPAM*.com, and sometimes lurk on freenode #mongodb as bwmcadams. Docs for core MongoKit follow... ======== MongoKit ======== MongoDB_ is a great schema-less document oriented database. It have a lot of driver for many langages (python, ruby, perl, java, php...). .. _MongoDB : http://www.mongodb.org/display/DOCS/Home MongoKit is a python module that brings structured schema and validation layer on top of the great pymongo driver. It has be written to be simpler and lighter as possible with the KISS and DRY principles in mind. Features ======== * schema validation (wich use simple python type for the declaration) * nested and complex schema declaration * required fields validation * default values * custom validators * inheritance and polymorphisme support * versionized document support (still in alpha stage) * partial auth support (it brings a simple User model) A quick example =============== MongoDocument are enhanced python dictionnary with a ``validate()`` method. A MongoDocument declaration look like that:: >>> from mongokit.pylons import MongoDocument >>> import datetime >>> class BlogPost(MongoDocument): ... db_name = 'test' ... collection_name = 'tutorial' ... structure = { ... 'title':unicode, ... 'body':unicode, ... 'author':unicode, ... 'date_creation':datetime.datetime, ... 'rank':int ... } ... required_fields = ['title','author', 'date_creation'] ... default_values = {'rank':0, 'date_creation':datetime.datetime.utcnow} ... >>> blogpost = BlogPost() >>> blogpost['title'] = u'my title' >>> blogpost['body'] = u'a body' >>> blogpost['author'] = u'me' >>> blogpost.validate() >>> blogpost # doctest: +ELLIPSIS, +NORMALIZE_WHITESPACE {'body': u'a body', 'title': u'my title', 'date_creation': datetime.datetime(...), 'rank': 0, 'author': u'me'} >>> blogpost.save() And you can use more complex structure:: >>> class ComplexDoc(MongoDocument): ... db_name = 'test' ... collection_name = 'tutorial' ... structure = { ... "foo" : {"content":int}, ... "bar" : { ... int:{unicode:int} ... } ... } ... required_fields = ['foo.content', 'bar.$int'] Please, see the tutorial_ for more examples. .. _tutorial : http://bitbucket.org/namlook/mongokit/wiki/Home [ For any questions related to this fork, especially the Pylons & Autoref (and properties) support, rather than the core mongokit code, please contact myself (Brendan McAdams ) rather than namlook. I can be reached at NO*bwmcadams*SPAM@gmail.*OMGSPAM*.com, and sometimes lurk on freenode #mongodb as bwmcadams.] Refaction 0.0.1dev Web-based tool for sharing webfaction services using webfaction's API. Emanuel Calso Contents ======== * Installation_ * Configuration_ * Running_ * `Admin Info`_ * `User QuickStart`_ Installation ============ You can install Refaction using:: easy_install Refaction. Contents_ Configuration ============= Make a config file as follows:: paster make-config Refaction config.ini You need to edit the configuration file (ie, **development.ini**), and assign values to these: * webfaction_ip * webfaction_user * webfaction_passwd Contents_ Running ======= Tweak the config file as appropriate and then setup the application:: paster setup-app config.ini Run the application:: paster serve development.ini Contents_ Admin Info ========== Default username **admin** Default password **admin** Contents_ User QuickStart =============== #. Create an ***application*** #. Create a ***domain*** with corresponding ***subdomains*** #. Create a ***website*** a. Choose subdomains to assign to a website b. Choose application for specific paths Contents_ PylonsGenshi 0.1.0 Pylons Project Template Using Genshi As The Templating Language Pedro Algarvio What is PylonsGenshi? ===================== PylonsGenshi is a paster_ template based on the Pylons_ one but addressing Genshi_ as it's templating engine. It basicly provides Markup_ wrapped webhelpers and a Formencode_ validate decorator designed to work with Genshi_. For an up-to-date read of the documentation, please `Read the Documentation page on site`__. Instalation ----------- It's as easy as:: sudo easy_install PylonsGenshi Or if you wish to install current trunk:: sudo easy_install http://pastie.ufsoft.org/svn/sandbox/PylonsGenshi/trunk PylonsGenshi can optionally install the MinificationWebHelpers_ which would already be wrapped in Markup_ objects. To install that extra:: sudo easy_install PylonsGenshi[minification] .. _paster: http://pythonpaste.org/script/developer.html#templates .. _Pylons: http://pylonshq.com .. _Genshi: http://genshi.edgewall.org .. _Markup: http://genshi.edgewall.org/wiki/ApiDocs/0.4.x/genshi.core#genshi.core:Markup .. _Formencode: http://www.formencode.org/ .. __: http://pastie.ufsoft.org/wiki/PylonsGenshi .. _MinificationWebHelpers: http://pastie.ufsoft.org/wiki/MinificationWebHelpers AuthProxy 0.1.0dev middleware wsgi d authentification Laurent Tordjman UNKNOWN Sweepy 0.1.0 A very basic minesweeper clone written in Pylons Francis O Reilly ++++++ Sweepy ++++++ This is a very simple (and ugly) implementation of the well known mine sweeper type game, in the Pylons framework. No extra dependencies are needed above Pylons itself, except for easy_install. Installation ============ Assuming you have easy_install:: easy_install Sweepy paster make-config Sweepy config.ini Running Sweepy ============== Assuming you have permissions to run a webserver on port 80 of your local machine:: paster serve config.ini The game is now available at http://localhost . If not, you need to edit config.ini and change the port under the [server:main] section to a port you have permissions to use. This will usually be a port above 1024, e.g. 8000; and in that case the game is available at http://localhost:8000 Files ===== modwsgideploy 0.4.20dev Deploy Turbogears2 or Pylons via apache and modwsgi. Lukasz Szybalski Deployment using mod_wsgi and apache. Below instructions will tell you how to quickly deploy your turbogears2 app using mod_wsgi. Install modwsgideploy --------------------- PYPI ~~~~ You can install modwsgideploy from PyPi:: easy_install modwsgideploy Done. Source Install ~~~~~~~~~~~~~~ You also have a choice of getting the source and installing it. You should use this in a virtual environment, for example:: virtalenv --no-site-packages BASELINE source BASELINE/bin/activate Install [:Bazaar:] if its not already installed on your system:: easy_install bzr Branch out the code. This will pull all the revision history. If you want just the recent one use checkout:: bzr branch https://code.launchpad.net/~szybalski/modwsgideploy/trunk/ modwsgideploy_code Install it:: cd modwsgideploy_code/trunk python setup.py develop Run modwsgi_deploy ------------------ Go into your python application project folder and type in:: paster modwsgi_deploy Example ------- Here is a typical installation, from start to finish on Debian Linux. You might have to use you OS specific commands for installing apache. The steps are: 1) Install apache and modwsgi 2) Setup virtual environment and install tg2 3) Create tg2 app 'myapp' 4) Install modwsgideploy and tweak wsgi settings to fit your needs or use default settings. 5) Check if everything is running properly. In this case I will install apache using tools available from my Linux operating system:: aptitude install apache2 aptitude install libapache2-mod-wsgi virtualenv --no-site-packages BASELINE source BASELINE/bin/activate easy_install -i http://www.turbogears.org/2.0/downloads/current/index tg.devtools paster quickstart myapp Install modwsgideploy:: easy_install modwsgideploy Go into you app and run modwsgi_deploy command:: cd myapp paster modwsgi_deploy You should see an apache folder like this inside 'myapp':: myapp |-- apache | |-- README.txt | |-- myapp | |-- myapp.wsgi | `-- test.wsgi 1. Read the README.txt 2. myapp is a apache configuration file that you need to copy into your apache configuration folder after all the settings are set. 3. myapp.wsgi is an modwsgi script that is called from myapp apache file 4. test.wsgi is a test script that you can call to see if you modwsgi was properly installed and working. Edit myapp file to change any paths and/or apache configurations. Then copy to apache folder. On my operating system I copy this file to:: cp ./apache/myapp /etc/apache2/sites-available/ Enable the website. On my OS its:: a2ensite myapp /etc/init.d/apache restart Done Feedback -------- If you have a useful sample wsgi script or apache config that you would like to share, please sent it to Turbogears mailing list. repoze.what-pylons 1.0 The repoze.what v1 plugin for Pylons/TG2 integration Gustavo Narea ********************************************* The repoze.what plugin for Pylons integration ********************************************* This is an extras plugin for repoze.what which provides optional and handy utilities for Pylons applications using this authorization framework. Some of the features of the plugin include: * The utilities are ready to use: There's nothing additional to be configured before using. * 100% documented. Each component is documented along with code samples. * The test suite has a coverage of 100% and it will never decrease -- if it ever does, report it as a bug! * TurboGears 2 is officially supported as well. SchemaBot 0.1.0a5 Python package to automatically manage database schema version control when using SQLAlchemy. Databases can be easily upgraded or downgraded to any version of the schema. Chris Miles Quick SchemaBot Tutorial: Define your initial model and register as schema version 1:: >>> import sqlalchemy as SA >>> from schemabot import SchemaBot, SchemaManager >>> meta = SA.MetaData() >>> user_table = SA.Table("user", meta, ... SA.Column('id', SA.types.Integer), ... SA.Column('username', SA.types.Unicode), ... SA.Column('password', SA.types.Unicode), ... ) >>> default_admin_user = "INSERT INTO user (id, username, password) VALUES (1, 'admin', 'admin')" >>> schema_version_1_upgrade = [user_table, default_admin_user] >>> schema_version_1_downgrade = [user_table] >>> schema_mgr = SchemaManager() >>> schema_mgr.register(1, upgrade=schema_version_1_upgrade, downgrade=schema_version_1_downgrade) >>> engine = SA.create_engine('sqlite:///test1.db') >>> schemabot = SchemaBot(schema_mgr, engine=engine, create_table=True) >>> (model_version, current_db_version) = schemabot.version_check() >>> print (model_version, current_db_version) (1, 0) >>> if model_version != current_db_version: ... schemabot.schema_update() >>> print schemabot.get_current_version() 1 In another terminal (don't close the above Python session) examine the resulting database:: $ sqlite3 test1.db Loading resources from /Users/chris/.sqliterc SQLite version 3.4.0 Enter ".help" for instructions sqlite> .tables schemabot_version user sqlite> .schema user CREATE TABLE user ( id INTEGER, username VARCHAR, password VARCHAR ); sqlite> SELECT * FROM schemabot_version; current_version --------------- 1 sqlite> SELECT * FROM user; id username password ---------- ---------- ---------- 1 admin admin Return to the existing Python session, define schema version 2 and upgrade:: >>> address_table = SA.Table('address', meta, ... SA.Column('id', SA.types.Integer), ... SA.Column('user_id', SA.types.Integer, SA.ForeignKey('user.id')), ... SA.Column('street', SA.types.Unicode), ... SA.Column('city', SA.types.Unicode), ... ) >>> schema_version_2 = [address_table] >>> schema_mgr.register(2, upgrade=schema_version_2, downgrade=schema_version_2) >>> (model_version, current_db_version) = schemabot.version_check() >>> print (model_version, current_db_version) (2, 1) >>> if model_version != current_db_version: ... schemabot.schema_update() >>> print schemabot.get_current_version() 2 In another terminal, examine the database:: $ sqlite3 test1.db Loading resources from /Users/chris/.sqliterc SQLite version 3.4.0 Enter ".help" for instructions sqlite> .tables address schemabot_version user sqlite> .schema address CREATE TABLE address ( id INTEGER, user_id INTEGER, street VARCHAR, city VARCHAR, FOREIGN KEY(user_id) REFERENCES user (id) ); sqlite> SELECT * FROM schemabot_version; current_version --------------- 2 Return to the existing Python session. Let's downgrade the schema back to the initial state (version 0). We will enable SQLAlchemy statement logging (echo) so we can see the action as it happens:: >>> engine.echo = True >>> schemabot.schema_update(version=0) 2009-05-27 13:46:08,690 INFO sqlalchemy.engine.base.Engine.0x...9a10 SELECT schemabot_version.current_version FROM schemabot_version 2009-05-27 13:46:08,691 INFO sqlalchemy.engine.base.Engine.0x...9a10 [] 2009-05-27 13:46:08,691 INFO sqlalchemy.engine.base.Engine.0x...9a10 BEGIN 2009-05-27 13:46:08,693 INFO sqlalchemy.engine.base.Engine.0x...9a10 DROP TABLE address 2009-05-27 13:46:08,693 INFO sqlalchemy.engine.base.Engine.0x...9a10 () 2009-05-27 13:46:08,696 INFO sqlalchemy.engine.base.Engine.0x...9a10 DROP TABLE user 2009-05-27 13:46:08,697 INFO sqlalchemy.engine.base.Engine.0x...9a10 () 2009-05-27 13:46:08,699 INFO sqlalchemy.engine.base.Engine.0x...9a10 UPDATE schemabot_version SET current_version=? 2009-05-27 13:46:08,700 INFO sqlalchemy.engine.base.Engine.0x...9a10 [0] 2009-05-27 13:46:08,701 INFO sqlalchemy.engine.base.Engine.0x...9a10 COMMIT >>> print schemabot.get_current_version() 2009-05-27 13:47:06,115 INFO sqlalchemy.engine.base.Engine.0x...9a10 SELECT schemabot_version.current_version FROM schemabot_version 2009-05-27 13:47:06,115 INFO sqlalchemy.engine.base.Engine.0x...9a10 [] 0 Swapping back to look at the database directly:: $ sqlite3 test1.db Loading resources from /Users/chris/.sqliterc SQLite version 3.4.0 Enter ".help" for instructions sqlite> .tables schemabot_version sqlite> SELECT * FROM schemabot_version; current_version --------------- 0 twFusionCharts 0.3dev Widgets for FusionChartsFree Tiago Cordeiro Marques Widgets for FusionChartsFree_ based on TGFusionCharts_ .. _TGFusionCharts: http://www.thesamet.com/TGFusionCharts/ .. _FusionChartsFree: http://www.fusioncharts.com/free/ ======== Install ======== easy_install twFusionCharts ==================================== Configuring ToscaWidgets with Pylons ==================================== See http://wiki.pylonshq.com/display/toscawidgets/Using+twForms+with+Pylons.+Part+1?showComments=false#id5 =========================== Usage Example with Pylons =========================== Controller:: from tw.fusioncharts import Column3DChartWidget, SingleSeriesChart def index(self): c.widget = Column3DChartWidget( chart_id='chart1', width=400, height=200, chart=SingleSeriesChart( [3,4,1,5], caption="New Incoming Links")) return render('/page.mako') Template (page.mako):: <html><head></head> ${h.literal(c.widget.render())} </html> Restler 0.6.0 RESTful base controller for Pylons 1.0 and SQLAlchemy 0.6. Wyatt L Baldwin Restler is a controller for Pylons projects that provides a set of default RESTful actions that can be overridden as needed. The Restler project is hosted at Google Code. Please see http://code.google.com/p/restler/ for more details, documentation, etc. Restler was originally extracted from the byCycle bicycle trip planner (http://bycycle.org). -
>Mirror PyPI MetaData
You can download our current PyPI MetaData from us: PyPI Mirrored MetaData
Thank you for choosing TurboGears.
TurboGears is a open source front-to-back web development framework written in Python. Copyright (c) 2005-2009