Re: Plugin architecture
Don't forget Django is a full stack framework, so plugins are easier to swap as they rely on the same stack. One of the great things about Pylons is you can cherry pick the best of breed components. The downside of this are plugins for pylons would be coupled to the initial implementations, which may require components not in your stack... It might be an idea to have an area on the Pylons site where people can link to github, bitbucket etc... pylons projects that are opensource and users can then pick, adapt and use in their new sites. Ross On Wed, May 6, 2009 at 9:23 PM, Brian Beck exo...@gmail.com wrote: On Apr 28, 12:25 pm, Ben Bangert b...@groovie.org wrote: The key difference between Django style re-use and repoze.bfg/Zope style re-use is how much life is going to suck down the road maintaining the apps. When you consider how Django approaches it, it seems like this will be a pain unless you're a DVCS master and are sure to use it because say you have: Site 1: - Comments app - Reviews app Site 2: - Comments app - Reviews app - Articles app Technically each 'app' in Django is just a sub-dir, so if you have 2+ sites, and you make a huge set of improvements to the Reviews app, odd's are each site project itself is in its own version repository, each app *itself* is merely in the larger project. So it becomes a bit of a hassle ensuring that your Reviews app is up to date on each site, and upgrading individual app's is problematic. Just thought I'd clear this up: Django apps are just sub-dirs in the sense that any Python module is just a sub-dir -- they can be installed like any other Python package and don't have to live in the project. Django just happens to add your project's directory to the Python path. -- Brian Beck / Adventurer of the First Order / www.brianbeck.com Unstoppable Rocket, LLC / www.unstoppablerocket.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
On Apr 28, 12:25 pm, Ben Bangert b...@groovie.org wrote: The key difference between Django style re-use and repoze.bfg/Zope style re-use is how much life is going to suck down the road maintaining the apps. When you consider how Django approaches it, it seems like this will be a pain unless you're a DVCS master and are sure to use it because say you have: Site 1: - Comments app - Reviews app Site 2: - Comments app - Reviews app - Articles app Technically each 'app' in Django is just a sub-dir, so if you have 2+ sites, and you make a huge set of improvements to the Reviews app, odd's are each site project itself is in its own version repository, each app *itself* is merely in the larger project. So it becomes a bit of a hassle ensuring that your Reviews app is up to date on each site, and upgrading individual app's is problematic. Just thought I'd clear this up: Django apps are just sub-dirs in the sense that any Python module is just a sub-dir -- they can be installed like any other Python package and don't have to live in the project. Django just happens to add your project's directory to the Python path. -- Brian Beck / Adventurer of the First Order / www.brianbeck.com Unstoppable Rocket, LLC / www.unstoppablerocket.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
I've been having some luck using Trac's component architecture to create plugins for my pylons project. Each plugin is installed using easy_install, and registers itself with a certain entry point name, which is discovered by the pylons app during startup. I have - a Component which adds new directories to the genshi search path for templates, - one which can find the new controllers to service the request, and adds them to the routes mapper so all routing is still done from routing.py, - another which allows you to define new SQLAlchemy model stuff, and it's all found and loaded together (if you need that), - and a couple others I can't think of right now It's working out pretty well, but it's a bit messy in places. I started blogging about it on http://brennantodd.com - but I've been much too lazy to do any more than the one post from a few months ago. As mentioned by others above, I have one package which contains the majority of my business logic (models, library functions, etc) which is not a Pylons project. Then my pylons site imports from that core package where necessary, and just loads things through the plugin system in other places. Other plugins depend on that core package, but any additional models/views/controllers they provide are discovered by the pylons app through the component system automatically. This is why I haven't blogged any more about this - I'm not sure I make any sense... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
On Thu, Apr 30, 2009 at 2:09 AM, Brennan Todd brent...@gmail.com wrote: I've been having some luck using Trac's component architecture to create plugins for my pylons project. It would be pretty badass if there was a Pylons project shell that had Trac like plugins that was open sourced. Each plugin is installed using easy_install, and registers itself with a certain entry point name, which is discovered by the pylons app during startup. I have a Component which adds new directories to the genshi search path for templates, one which can find the new controllers to service the request, and adds them to the routes mapper so all routing is still done from routing.py, another which allows you to define new SQLAlchemy model stuff, and it's all found and loaded together (if you need that), and a couple others I can't think of right now It's working out pretty well, but it's a bit messy in places. I started blogging about it on http://brennantodd.com - but I've been much too lazy to do any more than the one post from a few months ago. As mentioned by others above, I have one package which contains the majority of my business logic (models, library functions, etc) which is not a Pylons project. Then my pylons site imports from that core package where necessary, and just loads things through the plugin system in other places. Other plugins depend on that core package, but any additional models/views/controllers they provide are discovered by the pylons app through the component system automatically. This is why I haven't blogged any more about this - I'm not sure I make any sense... -- Cheers, Noah --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
On Mon, Apr 27, 2009 at 2:22 PM, Jonathan Vanasco jonat...@findmeon.comwrote:
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.
This is effectively how I did it, back in the day when I was doing stuff
like this. It might be useful to describe this, as it at least worked, even
if it didn't feel incredibly decoupled (and maybe this can't be that
decoupled). I think it helps to enumerate the issues; my personal pet peeve
with these plugin discussions is that they aren't sufficiently rooted in use
cases.
This was at my previous employer, Imaginary Landscape, where we did lots of
bespoke web sites, and we were starting to create reusable web applications
for clients. A typical client would use 2-5 applications we sold them,
integrated into one site and customized to some degree. We used Paste, and
it looked pretty similar to what Paste is currently, as well as PasteWebKit
for the framework (which is crufty but workable).
Each application was an independent application, in exactly the way a Pylons
application works. Each time we set up an application we'd edit the Apache
configuration to redirect a certain path (e.g., /gallery/) to the client's
Paste server. We used one server per client. Then we had configuration
like:
# main.ini
[DEFAULT]
site_name = bobs_food_emporium
site_title = Bob's Food Emporium
auth_secret = 59482e34d
... a couple other client-specific variables here ...
[composite:main]
use = egg:Paste#urlmap
/gallery = config:gallery.ini
/menu = config:menu.ini
/login = config:login.ini
... etc ...
#gallery.ini
[app:main]
use = egg:IscapeGallery
... some gallery-specific configuration ...
From there most of the rest of the framework happened in a single controller
superclass we had. It was entirely equivalent to having a BaseController
subclass that all your application in turn subclass from. Anything that
would go in the Pylons helpers module would typically be a method on the
this class, so it all got carried over. There was also a simple dispatch
system that made it possible to mix in some functionality (
http://svn.w4py.org/Component/trunk). For instance, the template renderer
used that (http://svn.w4py.org/ZPTKit/trunk). We didn't *have* to use this,
because we didn't really need to remix these pieces -- we always used Zope
Page Templates, we always used the same auth system (
http://svn.w4py.org/LoginKit/trunk) etc. But I developed this stuff long
before this system, so it did make it possible to incrementally do this
development.
All our applications used a template search path, in something like
/www/sites/${client_name}/templates/${app_name}/${template_name}. This was
a *huge* feature for us, because 90% of the client customizations we did, we
did by copying a template from the application into this directory and
changing it. No programmers needed to be involved in doing this. Towards
the end of my stint we were thinking about making this more pluggable so
simple text changes didn't require copying templates (basically so there was
a through-the-web interface to customize all the little chunks of text).
Also, all applications used templates that subclassed from one of two
templates (an admin template for internal screens, and a site template).
This template was big and hairy and drew heavily from code in the common
subclass. This arranged all the navigation, which included all the
applications in the system. To get a list of all the applications and a
bunch of configuration about how they were laid out, there was a second
config file. This config file regularly referred to things that weren't in
Paste or might not have even been hosted locally (per this pattern:
http://blog.ianbicking.org/2008/12/27/avoiding-silos-link-as-a-first-class-object/).
This file could use indirection similar to how use = config:... works in
Paste Deploy config files, and it would look like use = egg:MyApp, and it
would look for MyApp.egg-info/iscape_tool.ini, and you could override
specific values from that.
For identification we used auth_tkt cookies, and authentication was checked
in the superclass (in the equivalent of __before__). An application was
always mounted at /login that could actually set this cookie. We didn't use
middleware.
For authorization we eventually created a system where we'd define
application-local permissions, and then map those to site-wide roles via an
XML file, which we could override on a per-client basis. Applications would
manually check for permissions. A separate application managed users and
permissions (built into the login app, I believe). We put a lot of this
role information into the auth_tkt cookie (database sharing wasn't
necessary), though
Re: Plugin architecture
This is likely relevant to all the above discussion: http://docs.repoze.org/plugin/ and: http://svn.repoze.org/repoze.plugin/trunk/ At least its my best shot at creating something like the ZCA without most of the baggage (no interfaces, no XML). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
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. This was the killer for Pylons for me, see: http://groups.google.com/group/pylons-discuss/browse_thread/thread/14aef22ddb90347f/614bf25ee1f73d2f?lnk=gstq=rsyring#614bf25ee1f73d2f I would have loved to use Pylons, it was exactly what I wanted, except for that issue. We had to be able to modularize our code and plug-and- play with other apps (including things like sharing a main configuration, template, DB, etc.). I ended up creating a different framework with the intention of having it be like Pylons in spirit but like Django in modularity. http://pypi.python.org/pypi/pysapp If Pylons ever ends up incorporating something that would allow you to modularize parts of the app, I would most likely drop my own and move over. I really hate maintaining *another* web framework, but the necessity was there. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
On Apr 27, 2009, at 3:01 PM, Mike Orr wrote: 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.) I think TG2 will likely have a working modularity system first, which is fine since it'll be based on Pylons and should apply to us too. The key difference between Django style re-use and repoze.bfg/Zope style re-use is how much life is going to suck down the road maintaining the apps. When you consider how Django approaches it, it seems like this will be a pain unless you're a DVCS master and are sure to use it because say you have: Site 1: - Comments app - Reviews app Site 2: - Comments app - Reviews app - Articles app Technically each 'app' in Django is just a sub-dir, so if you have 2+ sites, and you make a huge set of improvements to the Reviews app, odd's are each site project itself is in its own version repository, each app *itself* is merely in the larger project. So it becomes a bit of a hassle ensuring that your Reviews app is up to date on each site, and upgrading individual app's is problematic. TG2 wants to avoid that, and of course this is where the Zope stuff comes in, because its component architecture allows each app to be its own package, and you can just configure it inside your project, and provide controller, model, template overrides as desired. Of course, if you have a really good VCS, like one of the DVCS's, it might not be too horrible to manage the apps the way Django does. I'd love to hear from someone who has managed 5 Django sites that share several apps between them, and how they manage feature upgrades in an individual app amongst all the sites using it, because it just doesn't strike me as being very maintainable. As Mike mentions, we're leaning the same way as TG2 and repoze.bfg, and using one or two small packages that have been split of from Zope which handle this stuff rather well. Not sure when it'll make its way into Pylons trunk though, as right now we're working on getting 1.0 out. Including the Zope Component Architecture and such to allow this would definitely be a bigger leap than the one to 1.0, so that might be thought of as Pylons 2.0 material (the version increase mainly just to represent the change in how you'll declare the application configuration). Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Re: Plugin architecture
On Apr 28, 8:42 am, Randy Syring rsyr...@gmail.com wrote: 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. This was the killer for Pylons for me, see: http://groups.google.com/group/pylons-discuss/browse_thread/thread/14... Regarding the discussion of the model over there, IMHO the model almost never should reside *within* the Pylons app, except for very simple sites. It should be a separate package that all your apps can import. As far as plugins, it seems to me that the things people are trying to do are do-able with Pylons, but there's just not a standard approach, which could be good or bad, depending on your perspective. I would have loved to use Pylons, it was exactly what I wanted, except for that issue. We had to be able to modularize our code and plug-and- play with other apps (including things like sharing a main configuration, template, DB, etc.). I ended up creating a different framework with the intention of having it be like Pylons in spirit but like Django in modularity. http://pypi.python.org/pypi/pysapp If Pylons ever ends up incorporating something that would allow you to modularize parts of the app, I would most likely drop my own and move over. I really hate maintaining *another* web framework, but the necessity was there. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
On Tue, Apr 28, 2009 at 12:01 AM, Mike Orr sluggos...@gmail.com wrote: It works, but that's a pain if you need to put your Pylons authorization system around it. It's not a real pain if you use repoze.who/what 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.) ZCA can be a good thing, but it also can be a mess. When you have too much interfaces and/or zcml in your code it can take a few hours to retrieve where a bug came from. Having a more advanced plugin system can be a good thing but what i like in pylons is that it's a *very* simple framework. 1 url = 1 method. Please, keep it simple. -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
On Apr 28, 2009, at 10:22 AM, Gael Pasgrimaud wrote: ZCA can be a good thing, but it also can be a mess. When you have too much interfaces and/or zcml in your code it can take a few hours to retrieve where a bug came from. Having a more advanced plugin system can be a good thing but what i like in pylons is that it's a *very* simple framework. 1 url = 1 method. Please, keep it simple. Yes, this is the dilemma. Any plug-in system increases the necessary complexity of the application. If you use sub-dirs for every project, your complexity is in managing sub-directories of projects as if they were packages. If we use ZCA to handle plug-in's, then there's the complexity it brings. The only other option is what Jonathan mentioned, which is where you have a package of controllers that you import in your own controller and sub-class as needed. I should note that the goal of using a system like the ZCA in Pylons, would be to only have core aspects of the framework using interfaces. A web developer not writing plug-in's would never smell/see/hear an interface in their code. So you'd only have to deal with interfaces if you're extending core aspects of the framework, or writing plug-ins. I'd be curious to look over Jonathan's approach a bit more, if a 'standard' definition for how the controllers should be pulled in, and how to extend the template search paths properly could be reached, that would probably be the simplest scheme that retains the separateness of a package for maintaining versions, while still being easy enough to customize. Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Re: Plugin architecture
On Tue, Apr 28, 2009 at 10:22 AM, Gael Pasgrimaud g...@gawel.org wrote: On Tue, Apr 28, 2009 at 12:01 AM, Mike Orr sluggos...@gmail.com wrote: It works, but that's a pain if you need to put your Pylons authorization system around it. It's not a real pain if you use repoze.who/what Yes, but some people have existing auth code (and logging code) which is working and would be too much work to port to repoze.who. Ben wrote: I'd be curious to look over Jonathan's approach a bit more, if a 'standard' definition for how the controllers should be pulled in, and how to extend the template search paths properly could be reached, that would probably be the simplest scheme that retains the separateness of a package for maintaining versions, while still being easy enough to customize. The most difficult problem seems to be controllers, and the 'controller_scan' argument in Routes which seems useless. (We had to hardcode the controllers in our GUI BILS app because of some incompatibility with py2exe.) Several people have asked how to have controllers in various packages and then pull in a selection of them. The simplest method is stub modules in the controllers directory that import the actual controllers. But maybe we can find something more flexible. -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
On Apr 28, 11:36 am, Mike Orr sluggos...@gmail.com wrote: On Tue, Apr 28, 2009 at 10:22 AM, Gael Pasgrimaud g...@gawel.org wrote: On Tue, Apr 28, 2009 at 12:01 AM, Mike Orr sluggos...@gmail.com wrote: It works, but that's a pain if you need to put your Pylons authorization system around it. It's not a real pain if you use repoze.who/what Yes, but some people have existing auth code (and logging code) which is working and would be too much work to port to repoze.who. Ben wrote: I'd be curious to look over Jonathan's approach a bit more, if a 'standard' definition for how the controllers should be pulled in, and how to extend the template search paths properly could be reached, that would probably be the simplest scheme that retains the separateness of a package for maintaining versions, while still being easy enough to customize. The most difficult problem seems to be controllers, and the 'controller_scan' argument in Routes which seems useless. (We had to hardcode the controllers in our GUI BILS app because of some incompatibility with py2exe.) Several people have asked how to have controllers in various packages and then pull in a selection of them. The simplest method is stub modules in the controllers directory that import the actual controllers. But maybe we can find something more flexible. Like, instead of importing controllers from directories, importing them from packages? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
Previously Mike Orr wrote: The most difficult problem seems to be controllers, and the 'controller_scan' argument in Routes which seems useless. (We had to hardcode the controllers in our GUI BILS app because of some incompatibility with py2exe.) Several people have asked how to have controllers in various packages and then pull in a selection of them. The simplest method is stub modules in the controllers directory that import the actual controllers. But maybe we can find something more flexible. If you decide to use zope.component a controller could be a named utility. You could then register it like so: class BaseController(object): This is the standard Pylons base controller class. implements(IPylonsController) class MyController(BaseController): My very own controller. registerUtility(MyController, name=my_controller) and Pylons could get a list of all utilities using something like this: controllers = getUtilitiesFor(IPylonsController) This prevents the need to skin directories as currently happens, and will allow you to put your controllers anywhere you want. You can also selectively do the registerUtility calls, override already registered controllers or remove controller registrations. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
On Apr 28, 2009, at 2:43 PM, Wichert Akkerman wrote: If you decide to use zope.component a controller could be a named utility. You could then register it like so: class BaseController(object): This is the standard Pylons base controller class. implements(IPylonsController) class MyController(BaseController): My very own controller. registerUtility(MyController, name=my_controller) Yikes! :) I was trying to only include interfaces enough such that an end user would never have to see them but they'd be helpful to allow/encourage plug-ins. The second a Pylons developer has to start knowing interfaces, utilities, registering things *just* to get the basic app working, Pylons has lost something I think is very important. I was aiming for any potential use of the zope stuff purely for use with plug-ins, or changing core aspects of Pylons that are currently difficult to tweak. Though its definitely true that even making a small basic app might involve an extra step to allow for pluggability. Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
Re: Plugin architecture
Previously Ben Bangert wrote: On Apr 28, 2009, at 2:43 PM, Wichert Akkerman wrote: If you decide to use zope.component a controller could be a named utility. You could then register it like so: class BaseController(object): This is the standard Pylons base controller class. implements(IPylonsController) class MyController(BaseController): My very own controller. registerUtility(MyController, name=my_controller) Yikes! :) Why the yikes? The only change for a Pylons user is adding a single line to register the controller. The interface that is used to manage the registrations can be hidden in the BaseController class and internal pylons logic - people may never need to know about it. This gives you a lot of extra flexbility and pluggability, at the expense of asking people to add a single line of code for each controller. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
On Tue, Apr 28, 2009 at 3:09 PM, Ben Bangert b...@groovie.org wrote: On Apr 28, 2009, at 2:43 PM, Wichert Akkerman wrote: If you decide to use zope.component a controller could be a named utility. You could then register it like so: class BaseController(object): This is the standard Pylons base controller class. implements(IPylonsController) class MyController(BaseController): My very own controller. registerUtility(MyController, name=my_controller) Yikes! :) I was trying to only include interfaces enough such that an end user would never have to see them but they'd be helpful to allow/encourage plug-ins. The second a Pylons developer has to start knowing interfaces, utilities, registering things *just* to get the basic app working, Pylons has lost something I think is very important. I was aiming for any potential use of the zope stuff purely for use with plug-ins, or changing core aspects of Pylons that are currently difficult to tweak. Though its definitely true that even making a small basic app might involve an extra step to allow for pluggability. We are talking about plugins at two different levels, the framework level and the application level. Ben is interested in the framework level; some others are interested in the application level. At this point it would be foolish to exclude either one, because that would just make the framework rigid and lead to Pylons 3.0 down the line. [1] Because the users who want application components are not going to go away, and we will forever be getting questions like Why doesn't Pylons have plug-in applications like Django does? I'll go write another framework that does. But at the same time we don't want to burden application developers with extra steps if they don't need the component features. [1] Like the transit authority in Seattle, which laid down grade-separated light rail most of the way but put four miles on the surface to save money. Which just means they'll have to come back and elevate it or put it underground later, at more expense than if they'd just done it that way in the first place. -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
On Wed, Apr 29, 2009 at 12:19 AM, Wichert Akkerman wich...@wiggy.net wrote:
Previously Ben Bangert wrote:
On Apr 28, 2009, at 2:43 PM, Wichert Akkerman wrote:
If you decide to use zope.component a controller could be a named
utility. You could then register it like so:
class BaseController(object):
This is the standard Pylons base controller class.
implements(IPylonsController)
class MyController(BaseController):
My very own controller.
registerUtility(MyController, name=my_controller)
Yikes! :)
Why the yikes? The only change for a Pylons user is adding a single line
to register the controller. The interface that is used to manage the
registrations can be hidden in the BaseController class and internal
pylons logic - people may never need to know about it. This gives you a
lot of extra flexbility and pluggability, at the expense of asking
people to add a single line of code for each controller.
The real problem is that a page is a controller *and* one ore more
templates. If you want to write a real pluggable system you need to
allow to register both templates and controllers. You also need a
standard template (eg: site.mako or main_template in plone) to insert
the output of the plugged app to the right place.
That's why I said that wsgi is enough for me because you can already
do that with Deliverance or in a controller with lxm or pyquery.
def MyController(environ, start_response):
html = PyQuery(app(environ, start_response))
return render('/site.mako',
extra_vars={'column_one':str(html('#column_one')),
'main':str(html('#main'))})
Wichert.
--
Wichert Akkerman wich...@wiggy.net It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Plugin architecture
On Tue, 2009-04-28 at 15:09 -0700, Ben Bangert wrote: On Apr 28, 2009, at 2:43 PM, Wichert Akkerman wrote: If you decide to use zope.component a controller could be a named utility. You could then register it like so: class BaseController(object): This is the standard Pylons base controller class. implements(IPylonsController) class MyController(BaseController): My very own controller. registerUtility(MyController, name=my_controller) Yikes! :) I was trying to only include interfaces enough such that an end user would never have to see them but they'd be helpful to allow/encourage plug-ins. The second a Pylons developer has to start knowing interfaces, utilities, registering things *just* to get the basic app working, Pylons has lost something I think is very important. I was aiming for any potential use of the zope stuff purely for use with plug-ins, or changing core aspects of Pylons that are currently difficult to tweak. Though its definitely true that even making a small basic app might involve an extra step to allow for pluggability. If I may pipe in from the peanut gallery, I think it is also critical for these decisions to think from a marketing perspective about *who* a Pylons target user really is. And it's definitely not the same person as a target Django user. While it is great to keep pylons simple in a simple-is-elegant context, I do not personally think Pylons should forgo power for end-user simplicity. IMHO, people who are going to be turned off by having to understand some extra concepts like zope interfaces and having to make a call to a registry really aren't likely to be choosing Pylons, those are Django's good-fit. On the other hand, I think a lot of people ( me included! ) have gravitated to pylons when they realized that they were going to be doing a lot of complex stuff with a big app, and didn't want the framework limiting them. Those people are the type who are going to be attracted to the possibility of using more from the ZCA world and are not going to mind a bit of extra boilerplate to have a truly flexible system with greater code reuse potential in the long run. my two cents from a recent Pylons and ZCA convert! Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
On Apr 28, 12:25 pm, Ben Bangert b...@groovie.org wrote: The key difference between Django style re-use and repoze.bfg/Zope style re-use is how much life is going to suck down the road maintaining the apps. When you consider how Django approaches it, it seems like this will be a pain unless you're a DVCS master and are sure to use it because say you have: Site 1: - Comments app - Reviews app Site 2: - Comments app - Reviews app - Articles app Technically each 'app' in Django is just a sub-dir, so if you have 2+ sites, and you make a huge set of improvements to the Reviews app, odd's are each site project itself is in its own version repository, each app *itself* is merely in the larger project. So it becomes a bit of a hassle ensuring that your Reviews app is up to date on each site, and upgrading individual app's is problematic. I am not sure how applicable this will be to Pylons (and I know nothing about Zope), but here is how I solved the said problem in pysmvt: The simplest project would have one application (myapp) and the said application would have at least one module. All views (controllers)/ templates/routes reside in the module, which we will call default, which is stored in the modules directory of the application directory. The base myapp directory must be on the python path so that it could be imported using 'import myapp'. Now, lets say you want to add a news module to myapp. If you are building it from scratch, just create a directory like .../myapp/ modules/news, with the appropriate files and directories, and start coding. Adjust news/settings.py or myapp/settings.py to have the appropriate routes, and you are off and running. However, lets say that the news module already exists and you want to use it in myapp. Instead of creating the news directory manually, make it an SVN external (or equivalent). Ah, but what happens if you need to customize news in a way you wouldn't want to commit to the main news module's trunk? Enter supporting applications. Create a new application, supportingapp. It doesn't even really need a setup file or anything, it just needs to be on the python path and have a modules directory. Now, use SVN externals on the supportingapp/ modules directory so that the news module is installed there. In myapp/settings.py, make a single entry so that the framework knows that myapp is using supporting app as a supporting application. The framework will now do hierarchical based imports looking at the main app first and then recursing into the supporting app(s) to find objects. So if the routing says '/news/list' maps to the NewsList view in the news module, then myapp will be searched first and when it isn't found, supportingapp will be searched, found, and displayed. Now, if you need to customize NewsList, you simply create a news module in myapp with a NewsList view and it will automatically override the NewsList view from supportingapp. Enter, myapp2, a different app that also needs to use the non-modified version of the news module. No problem, just tell myapp2 to use supportingapp as a supporting application. If a bug is found in the news module, it can be fixed in both applications by simply updating '.../supportingapp/modules/news'. I have found the concept of supporting (i.e. stacked) applications with inheritance to be helpful on a number of different levels. Since you don't have to use it, or even know about it, it is very easy to create a basic application. But the inheritance structure gives a lot of power and flexibility down the road. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
On Sunday, April 26, 2009, Gael Pasgrimaud g...@gawel.org wrote: On Sun, Apr 26, 2009 at 10:19 PM, Kless jonas@googlemail.com wrote: Does Pylons is going to build a plugin system for that can be easily shared/re-used the applications? As is made in Django. You can already plug any wsgi application/middleware to pylons. see http://pylonshq.com/docs/en/0.9.7/wsgi_support/ So i don't see the need of a plugin system. That's why wsgi is made for. What about a plugin system where plugins would provide Pylons controllers and routes (to these controllers)? So someone who has developed a general-interest controller could distribute for others to use it in their Pylons apps. -- Eric -- Eric Lemoine Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac, Cedex Tel : 00 33 4 79 44 44 96 Mail : eric.lemo...@camptocamp.com http://www.camptocamp.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
On Apr 27, 11:55 am, Eric Lemoine eric.lemo...@camptocamp.com wrote: On Sunday, April 26, 2009, Gael Pasgrimaud g...@gawel.org wrote: On Sun, Apr 26, 2009 at 10:19 PM, Kless jonas@googlemail.com wrote: Does Pylons is going to build a plugin system for that can be easily shared/re-used the applications? As is made in Django. You can already plug any wsgi application/middleware to pylons. see http://pylonshq.com/docs/en/0.9.7/wsgi_support/ So i don't see the need of a plugin system. That's why wsgi is made for. What about a plugin system where plugins would provide Pylons controllers and routes (to these controllers)? So someone who has developed a general-interest controller could distribute for others to use it in their Pylons apps. I haven't done this, but I'm pretty sure it's already possible by using the proper Paste config. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
On Apr 27, 12:22 pm, Jonathan Vanasco jonat...@findmeon.com 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
On Mon, Apr 27, 2009 at 1:13 PM, Wyatt Baldwin wyatt.lee.bald...@gmail.com wrote: On Apr 27, 12:22 pm, Jonathan Vanasco jonat...@findmeon.com 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 sluggos...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
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.) FWIW, I'm one user who things that would be hella cool. I would love see more Pylons/TG/Repoze interoperability and be able us more Zope technology or approaches for projects that get big. =) Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Plugin architecture
Does Pylons is going to build a plugin system for that can be easily shared/re-used the applications? As is made in Django. I know that TG2 is working on that. And I think that it's also important that pylons integrates a plugin system, this could speed up the grow up of pylons applications and so its community. I prefer use a framework that lets re-use applications easily as Django, and I'm sure that many people think as me. It's possible that Pylons has been better designed but at the end the most important is the community. And a great community is built letting to people that could re-use/share its applications. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
On Sun, Apr 26, 2009 at 10:19 PM, Kless jonas@googlemail.com wrote: Does Pylons is going to build a plugin system for that can be easily shared/re-used the applications? As is made in Django. You can already plug any wsgi application/middleware to pylons. see http://pylonshq.com/docs/en/0.9.7/wsgi_support/ So i don't see the need of a plugin system. That's why wsgi is made for. I know that TG2 is working on that. And I think that it's also important that pylons integrates a plugin system, this could speed up the grow up of pylons applications and so its community. I prefer use a framework that lets re-use applications easily as Django, and I'm sure that many people think as me. It's possible that Pylons has been better designed but at the end the most important is the community. And a great community is built letting to people that could re-use/share its applications. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
