On Tue, Feb 16, 2010 at 3:28 AM, mk <[email protected]> wrote: > Hello everyone, > > I need to write a rather large web app using Pylons. > > I'm trying to work out if it could be written as a series of plugins, some > of them realizing "core" functions, and some being addons, e.g. Email > Management or FTP Management would be core plugins and Accounting could be a > third-party plugin, working e.g. with FTP Management to calculate e.g. > bandwidth used by FTP. > > To give you some idea why I would try to do it this way: > > 1. Modularity. Separating, say, Accounting from Email Management makes sense > on an architectural level. > > 2. Extensibility by third parties. In order not to end up with > unmaintainable mess, communication between plugins should be handled via > some service interface over some sort of established protocol (I think). > > I was thinking that even the main page could just be a display page for > content produced by particular plugins (would template inheritance in Mako > be useful for this?). > > I found this: > > http://wiki.pylonshq.com/display/pylonscookbook/Using+Entry+Points+to+Write+Plugins > > But I'm not sure eggs would suffice: I would like to be able to register > plugins dynamically while the Pylons app is running and to be able to > dynamically create pages querying plugins from somewhere (the plugin data > could even be contained in SQLA backend). Say, the main app page queries > plugin list, and asks each plugin to create HTML content for its part of the > page in specified context (say, 'mainpage'), then displays the whole thing. > One thing that worries me a bit in such context would be an overhead. > > I do realize that in this case Pylons becomes sort of meta-framework, and > frankly I have no idea if this would work well, or if the whole thing would > just collapse in flames. > > How would you approach doing smth like this in Pylons? Is it even a good > idea? > > So far I've written only "hello world" sort of apps in Pylons (I wrote quite > a bit in straight mod_python using Mako and SQLA as components), so I would > appreciate the thoughts on the subject of people who have had more > experience with implementing actual apps in Pylons than I have.
There is no existing Pylons code for plugins that I'm aware of, but you may be able to leverage zope.interfaces, and there may be a relevant Repoze package that ties into it. The concept of plugins is related to interfaces/adapters, although I'm not sure how useful zope.interface would be in your context. Cc'ing Noah Gift who has been interested in plugins, and Chris McDonough who's a Repoze developer and has been studying the area of framework components. A quick web search came up with the following other leads: PyPI "plugin" search http://pypi.python.org/pypi?:action=search&term=plugin&submit=search http://wehart.blogspot.com/2009/01/python-plugin-frameworks.html "Python Plugin Frameworks", by W. Hart http://pypi.python.org/pypi/PlugBoard/0.2 PlugBoard, an application plugin system using Zope interfaces http://pypi.python.org/pypi/Plugins/0.5a1dev Plugins (part of the Peak project). Peak was the creator of Setuptools and entry points, but their software is kind of complex to learn. I wouldn't necessarily use any of these as-is but they may give you some ideas for structuring your suite. Pylons' URL dispatcher is static, so you can't really change routes or controllers at runtime. Well, maybe you can, but it's unsupported. This suggests you should funnel all your plugins through one controller, which would then delegate to the appropriate plugin. The plugin would prepare the response and return it to the controller. The plugins could take ``request``, ``response``, ``session``, and ``request.environ`` arguments as-is, or you could pass more specific variables as you wish. ``pylons.app_globals`` would be a good place to put a data structure containing the currently-active plugins. (Remember that app_globals is not thread safe; there was a pylons-discuss thread a few days ago talking about the right way to update it.) You'd have to write some kind of plugin management interface for activating plugins on the fly. Entry points and pseudo-controllers (controllers that are just a wrapper around an external WSGI application) are probably not what you want, because they can't be modified at runtime either. If you funnel all plugins through one controller action, all plugin URLs will have a common prefix (e.g., "/plugins/"). You can use routing variables to identify the plugin and its action, and pass the rest of the URL as a wildcard to the plugin. E.g., map.connect("plugin", "/plugins/{plugin}/{plugin_action}/{rest_of_url:.*}", controller="plugins", action="do_plugin") The plugin could also have its own routing map, which it would pass rest_of_url to. In that case you'd probably define the plugin as a class, and the routemap would be an instance variable or class variable. Doing a plugin action would involve calling plugin's .__call__ method or another method. Or if you know ahead of time which groups of plugins you'll have (email, files, etc), you can make a separate route and controller/action for each group. This may or may not be more convenient. For email management, take a look at TurboMail. It's default configuration is static (specified in the INI file), but it's flexible enough that your plugins may be able to use it, or they could each create their own turbomail objects if necessary.) -- Mike Orr <[email protected]> -- 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.
