On Tue, Feb 16, 2010 at 6: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. > > Regards, > mk > > -- > 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. > >
This is strictly my opinion, but pylons goal is not really to be pluggable in the sense you are thinking. That's not to say you can't devise your own scheme to compose a large app out of smaller pieces that you write or adapt. That being said, off the top of my head I can think of a number of ways to plug into pylons with varying degrees of success. #1 pylons can map a route to any wsgi callable, http://pylonsbook.com/en/1.1/the-web-server-gateway-interface-wsgi.html#wsgi-in-pylons-controllers I should mention you can also use paste urlmap to mount wsgi applications to a url outside of pylons. If merely passing along the request and returning the result is all you need, either of these 2 will work. If you need to give the app some extra context, then I think the middleware idea is the most appropriate for the environment but can lead to some really awkward coding(my opinion). #2 nothing is stopping you from defining models and controllers and views in a different package, and pythons import machinery still applies. there may be a little bit of work involved in initial setup (initializing the session for the model in the other package) but it's not impossible. And it would be something that you need to do anyway. #3 consider the pylons app the component. I eluded to this in item 1, but it's worth mentioning separately. Paste can be used to compose applications for you. Spend some time with this chapter. http://pythonpaste.org/do-it-yourself-framework.html One possibility is a bunch of small pylons(or any wsgi app) apps mounted at various url endpoints via urlmap. Some auth middleware in front of that, and perhaps using something like deliverance for the common look and feel. http://www.coactivate.org/projects/deliverance/introduction Notice I said any wsgi app. this is the magic of wsgi it allows a way for these kinds of things to be possible. Consider this, let's say you wanted something like bitbucket but it needed to be internal for your company because obviously your boss doesn't want the "intellectual property" being shared with competitors. This is possible, all the core pieces are there with a wsgi interface. Mercurial's hgweb and hgwebdir are wsgi applications. Trac can be run as a wsgi application MoinMoin is a wsgi wiki repoze.who or authkit for the authorization middleware deliverance to put it all under one theme ?? ================================= profit Hope that helps. There are other frameworks that are more purposely designed to have plugins, the thing is, those frameworks need to enforce an api and are then more restrictive than pylons. Some are more restrictive than others of course. That's the trade off -- Thomas G. Willis -- 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.
