On Mon, Apr 27, 2009 at 1:13 PM, Wyatt Baldwin <[email protected]> wrote: > > On Apr 27, 12:22 pm, Jonathan Vanasco <[email protected]> wrote: >> I've been working on such a project, and its a bit of a PITA.. >> >> The way Pylons works, you can't really consolidate all the Plugin >> stuff as 'neatly' as with other systems: ie- you can't really do an >> isolated tree that offers it's own MVC directories. >> >> But you can do something where you can import 'shared' controllers or >> models, and then just subclass them or use as-is.. and have your own >> templates folder. > > Why wouldn't this work: > > http://pythonpaste.org/deploy/#composite-applications > > [composite:main] > use = egg:Paste#urlmap > / = blog > /forum = forum > > [app:blog] > use = egg:MyPortOfWordPressToPython > > [app:forum] > use = egg:MyForum
It works, but that's a pain if you need to put your Pylons authorization system around it. As JonathanV said, Pylons is not really structured to plug in mini-apps the way Django is. But you can plug in WSGI applications via Paste Composite, or by a controller stub module, or you can return it in a controller action. Pylons apps can be embedded if you instantiate them with ``full_stack=False``, but you may need to adjust middleware.py because I'm not sure the default is ideal. WSGI is a rather clunky protocol. It works well for its core case of connecting an arbitrary application to an arbitrary HTTP server. It works OK for middleware although the API is primitive. You can use webob.Request/Response in your middleware to make it easier to work with. At PyCon, some of us experimented with a full plugin system (Zope Component Architecture) as used in repoze.BFG. It's too early to tell whether it would be feasable for a Pylons-like framework (and most of the developers are too busy to pursue it right now). But the theoretical idea would be to move some of the middleware to it, use it for part of Pylons internal configuration and environment.py, and perhaps expose it to the application developer for customization. And this may in turn allow for greater interoperability between Pylons, TG, BFG, and other external software, and simplify the configuration systems that they all use. (Deployment configuration a la development.ini would remain separate, maybe, depending on the framework developer's/application developer's desire.) -- 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 -~----------~----~----~----~------~----~------~--~---
