On Thu, 2009-06-25 at 23:01 -0700, Ben Bangert wrote: > On Jun 25, 2009, at 12:07 AM, Iain Duncan wrote: > > > Is there a mailing list or something where we can follow these > > discussions? > > Most of the discussions have taken place on IRC, and a bit took place > at PyCon, as it seems to take too long with too many misunderstandings > when its all done via e-mail threads (Maybe Wave would change that! ;). > > Summary of where we've gotten in the past few days for those curious, > but first, a warning. This is future-framework type stuff, Pylons > isn't going anywhere as its a solid project at this point. Pypes and a > future framework will have a migration path for Pylons users, and its > quite possible for many, there won't be any reason to migrate as > Pylons does all they need it to now. > > We (Chris McDonough and myself) have been exploring a core system from > which to start with a flexible component oriented framework. So far, > some of it is in the pypes code-base here, though its incredibly > prototype-ish: http://bitbucket.org/chrism/pypes/ > > It's rather different at the moment from Pylons, and somewhat similar > to repoze.bfg. It uses zope.interface and repoze.component to handle > having pluggable components, though a user would never see such a > thing (only a component developer that needs to make plugins). It's > being designed from the ground up to handle having plug-in apps (an > area I think Pylons fails at, and Django isn't scaling well to handle > with settings.py conflicts and issues). > > This means it supports things like being able to plug-in an app, that > needs to register some routes with the main mapper. One of my example > plug-in's/components, was being able to write a XMLRPC Blog backend > 'app', that I could easily use in any content-type app, merely by > supplying a path for it to answer on, and giving it an object it needs > to know how to store/retrieve/update the content it should handle. > > I feel the XML approach of repoze.bfg and Zope-type apps using ZCML > would be a major turn-off to the user audience, so I've been keen to > go with YAML for configuration. It also has the nice advantage that > YAML structures get parsed directly into Python dictionaries, and > things like true/false, and integers also become proper Python types > auto-magically. > > Chris wrote up a YAML based plugin to handle parsing the configuration > file (I'm referring to application/site configuration, stuff thats > currently split into environment.py, routing.py, and middleware.py). I > like it, but of course, some may not, here's what setting up a few > Routes-style connections might look like: > > --- !pypesviews > - path: /search/{keyword} > view: myapp.views:Search > action: search > > - path: /search > view: myapp.views:Search > action: index > > - path: / > view: myapp.views:Home > action: index > > etc. > > Of course, it'd also be easy to have a default scheme to remove the > need to manually specify where the controller (called view in this > case) actually is. It's also a lot easier to make things flexible with > this layout. For example, the bit at the top of this section, "--- ! > pypesview" is a YAML processor directive. The way Chris set it up, > which I think works out quite nicely, is that possible directives are > discovered using setuptools entrypoints. As the applicaiton config > file is parsed, each directive is called with the section under it, so > you will prolly have multiple sections, one for the routing stuff, > maybe a few for plug-in apps or components you're using (they can > register their own directives for use in your config file), etc. > > This would let me as a component maker write a XMLRPC backend app that > answers all the common API's (Blogger, Metaweblog, MovableType, etc), > and register a directive, so someone using it could just do: > > --- !blog-backend > path: /backend/xmlrpc > object: myapp.lib.apis:XMLRPC > > In this case, I'd make my directive look for and import the object, > which would be expected to provide some methods (basic CRUD style), so > that the XMLRPC code would be able to do what is requested. Just a > theoretical sample, but the goal is to make it as easy as possible to > use and create a wide array of flexible components and/or plug-in type > apps, without nearly as many of the restrictions or presumptions in a > Django type system. > > Some differences from Pylons: > - Pypes would have no globals of its own (migration adapters would be > available that populate Pylons style globals for a smoother transition) > - Pypes calls the code that handles being dispatched to, a 'view'. I > personally don't care that much anymore what its called, as the terms > MVC definitely doesn't work well in webapps to begin with, especially > since the thing that actually handles and determines what responds to > the request is the URL resolver/dispatcher, NOT the Pylons > 'controller', though it of course has a say in what happens to an > extent as well > - Pypes dispatcher uses a Routes mapper first, with 'fall-through' to > traversal (repoze.bfg/zope style, though for backwards compat with > TG2, could use a CherryPy style traverser) > > Anyways, that's about where we are now, and we're now working on some > code to play with these thoughts and see how they pan out.
Thanks Ben, that's very exciting. It would be cool if the discussion could be posted somewhere even as irc transcripts just to keep it more public. I imagine a focus point will come up soon enough. Even though it is all future thinking, this does make a difference to Pylons marketing. For example, I'm now 100% sure I want to keep using both Pylons and learning BFG, instead of wondering what the future will bring! Iain --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en -~----------~----~----~----~------~----~------~--~---
