On 05/23/2010 03:51 AM, Rufus Pollock wrote: > On 22 May 2010 21:25, Tim Black <[email protected]> wrote: > >> At least partial examples of 1 & 2 are provided by by TurboGears, though >> not as plugins. >> > As I understand it (I had a looked a *bit* before) TG admin is based > on dbsprockets + toscawidgets: > > <http://turbogears.org/2.0/docs/main/Extensions/Admin/index.html> > It looks to me like it depends on SQLAlchemy, too. > Is there any way for that tgext.admin to be re-usable in pylons? > I haven't tried, but since TurboGears is built on Pylons, tgext.admin might just work the same way it works in TurboGears. >> Though this is not what you're looking for, I'll mention that I'm >> beginning to create a very simple app-specific plugin framework here >> https://blueprints.launchpad.net/reformedchurcheslocator/+spec/feeds-plugin-framework. >> I've outlined a basic strategy for implementing the framework, but hope >> I might be able to glean some insight from other plugin frameworks as I go. >> > Interesting. From a quick look at the docs I assume this is to do with > caching (atom/rss?) feeds? Yes, it will cache atom/rss feeds, as well as "feeds" that are just existing HTML pages that we'll screen-scrape for content. > If so that at least one other example of a > standard plugin use-case and I we ourselves have implement this kind > of feed caching in http://www.openshakespeare.org/ as a way of pulling > content from a wordpress CMS into the main site (that's how word of > the day is generated for example: > <http://www.openshakespeare.org/word/read/bilbo>) > Are you using VDM for the feed caching? I note this demo: http://knowledgeforge.net/okfn/vdm/file/cb5116104817/vdm/sqlalchemy/demo_simple.py. CKAN (http://knowledgeforge.net/ckan/trac/) has features similar to what I'm trying to implement (versioning, tagging, groups, recent changes). I note http://wiki.okfn.org/ckan/doc/schema/--is it possible to make the following 4 kinds of packages (each with its own distinct database schema): congregations, people, offices, and roles, then make a one-to-many relationship where one congregation has many people, and each person has one or more officers or roles? I need to store data for church congregations and groups of congregations--data like the church name, address, latitude & longitude, phone number, website URL, email address, & names & contact info for its officers (pastor, elders, deacons) and other roles (clerk of session, treasurer, Sunday School superintendent).
I'm also finding the ideas in the CKAN documentation useful as I'm figuring out how to manage our federated church directory data. Where is the code or the docs on how you "exchange...metadata changesets between different CKAN instances"? That's going to be a key feature of the Reformed Churches Locator (RCL) software--one RCL instance will regularly read in feeds of other RCL instances' data. I'm planning to use UUIDs to avoid duplicate data, but am finding it tricky to prevent duplicate data from non-RCL feeds that don't provide a UUID. See https://blueprints.launchpad.net/reformedchurcheslocator/+spec/versioning for my initial methods of avoiding duplicates. I think your duplicate-avoiding code must be in here: http://knowledgeforge.net/ckan/hg/file/f6c0d4e0950a/ckan/getdata/ ; is that correct? > It also reminds me that another useful plugin would be (AMQP) > messaging/celery integration. Again this is something we have > experience of and could share our current approach. > Thank you. I read through AMQP & celery's docs and can't figure out how I would use them in RCL yet, but will keep them in mind for when I finally realize I need them in the future. : ) Tim >> Tim >> >> On 05/22/2010 02:12 PM, Rufus Pollock wrote: >> >>> Hi, >>> >>> At the Open Knowledge Foundation (http://www.okfn.org) we have used >>> Pylons for several of our projects (http://www.okfn.org/projects/). We >>> think it is a great framework. >>> >>> However, there are some standard components which it would be nice to >>> be able to "plugin" in a standard way -- e.g. users + auth, admin, >>> settings, comments (more examples plus details below). In many other >>> frameworks/platforms (including e.g. Django) you do indeed see some >>> sort of plugin frameworks in which this sort of functionality does >>> indeed become a plugin of some kind. >>> >>> Now, I'm well aware of Pylons different and more flexible (and IMO >>> better) approach compared to e.g. django. And that this architecture >>> may mitigate against providing any standard "plugin" (e.g. how do we >>> know which template framework -- mako, genshi, jinja, etc -- a given >>> pylons user is using ...). >>> >>> However, I think it is still possible to do something useful along >>> these lines -- even if a formal plugin framework isn't >>> possible/required just "packaging" up best-practice(s) *pattern* for >>> how to do standard stuff it would be very valuable (especially if a >>> pattern kept up to date!). >>> >>> Below I've given a list of some examples of the sorts of things that >>> could be "plugins". What else should be on that list? Is there >>> interest in having plugins? >>> >>> Regards, >>> >>> Rufus Pollock >>> Open Knowledge Foundation - http://www.okfn.org/ >>> >>> >>> ## Pylons plugin proposals >>> >>> ### 1. Users and Authentication - basic plugin to do users and >>> authentication out of the box >>> >>> * Openid + Form (email confirmation etc) >>> * Build on existing plugins (repoze.who, authkit, whatever) >>> * Tie in to existing model (sqlalchemy) object (or provide demo code >>> to create it) >>> * Even if just a demo that *works* it would be useful >>> * We've now done this ~ 6 times. There are commonalities and even if >>> this were just a demo it would be useful >>> >>> ### 2. Admin - lightweight admin system >>> >>> 1. Model CRUD - provided an existing solution nicely wrapped up or >>> just document how to do it and ensure it really works -- we've used >>> FormAlchemy plenty (and other options) but ensuring something "just >>> worked" would be useful >>> >>> 2. Settings module - think wordpress settings/options system >>> * DB Table + web user interface >>> * Config in db rather than ini file >>> >>> ### 3. Mini-CMS >>> >>> * Simple content management - post/page table plus editor >>> * Slave CMS - pull content from an RSS feed from e.g. wordpress or other >>> CMS >>> * We implemented this ourselves in http://openshakespeare.org >>> >>> ### 4. Commenting >>> >>> * Commenting is a common functionality across many applications >>> * A basic plugin that providing commenting functionality either >>> directly or pased on an existing pluggable service (e.g. disqus) would >>> be extremely useful >>> >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "pylons-discuss" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/pylons-discuss?hl=en. >> >> >> > > > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
