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. Cheers, Ben --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
