On Nov 5, 2010, at 1:50 PM, Jens Hoffrichter wrote: > Thanks to especially Graham and Mike to point out what the benefit for the > "end-user-developer" (a crude term, I know ;) ) will be with the > Pylons2/Pyramid move. > > When I started to read these posts, I was a bit concerned, too. I (we, my > company) have been long time Pylons users, and admittedly, we have seen more > changes in Pylons than we liked. I could understand the reasoning behind all > those changes, still, for the developer they pose a hazard in > long-term-evolution of a written app. > > Some of the things I mean: > > - The deprecation of rails-style webhelpers. We depend on those quite a bit > in our first application we wrote (and which is still live)
No worries, these are not dead! The WebHelpers package isn't going anywhere, and its still easy to use throughout your templates. > - Change in how to address a template (from "package.template" to > "package/template.mak") Ah, sorry if that's confusing. The dotted notation for a full 'resource specification' is optional: http://docs.pylonshq.com/pyramid/dev/narr/views.html#mak-or-mako-mako-template-renderer You can and do of course, configure Mako to have a template directory, and relative names like 'foo.mak' are assumed to exist in said template dir. The ability to use a full resource specification addresses a long-time noted issue with extending or re-using packages of your templates. While Mako lets you plugin multiple template paths, the overlap can get tricky to manage, being able to refer to a template with its package name is specifically to allow you to use templates that might be in another package for extending purposes. Consider the case where you have a set of templates you use in all your projects, wouldn't it be nice to have a package of those you just call into? And if you needed to tweak just one of those, you could override it with a template of your choice via the override API: http://docs.pylonshq.com/pyramid/dev/narr/resources.html#the-override-resource-api This is the start of where many frameworks are telling you to fork code.... ;) > - The move from implicit routes to explicit routes Yes, all routes do have to be explicit. I was moving that way in Pylons 1.x with Routes already actually, as the implicit naming and resolving done in Routes generally leads to more problems for users, than helping. > And if I thought a bit more, I would probably come up with a couple of more > examples, which have been problematic for us. The problem in there is, that > there normally is no smooth upgrade path, and no backwards compatibility, so > we are stuck with supporting a 0.9.6.2, a 0.9.7 and a 1.0 pylons app by now, > as no one would pay us a money for the complete rework the older apps need, > as for the customer, it would mean very little benefit. I've tried to provide as smooth an upgrade path as possible between various versions of Pylons. From the upgrade path's I've seen in other web frameworks, its one of the smoother ones... but the fact that so much configuration was in Python files rather than the framework has been very problematic as extensive changes are needed for upgrades as half the 'framework' is more or less assembled in the project itself. pyramid does not have this issue, as rather than having all its configuration innards in your project, you configure pyramid via hook points. > Don't get me wrong, I love pylons, and the first question we ask ourselves > when a new project comes in is, "Can we solve this in pylons, or do we have > to implement it with something different?", but the lack of continuity has > been a bit disheartening at times. > > Still, I would really be interested in why the subclassing of WSGIController > lead Pylons in an architectional dead end, just from a curious point of view > :) http://be.groovie.org/post/1347858988/why-extending-through-subclassing-a-frameworks is my main summary of the problems. I also have a bit more on this on the faq question here: http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just-continue-developing-the-pylons-1-0-code-base > I will take a look at the new packages as soon as I get around to it, but I'm > really curious by now. > > > But really, what does Pylons 1 need? We have already rejected larger > > Form/ORM/Auth dependencies. > > "@validate" needs a replacement; that's the only thing I can think of. > Maybe not the Pylons package itself (and I personally had no trouble using > @validate up to now), but one thing the whole Pylons eco system would hugely > benefit from (imo) is a database migration tool. I have looked into those > which have been announces (miraku and a couple of others), and all fall short. I'd love to spend more time on getting an 'official' one hammered out. Part of the reason for combining efforts, and going with pyramid for the base is that we need a strong, stable, extensible system to start building more helpful higher level tools. With a larger team of developers, this becomes much easier. I'm also trying to address ways the Pylons site failed to make it easy enough to get involved and contribute by increasing the amount of documentation on *how* to actually contribute. http://docs.pylonshq.com/#contributing So far, there's already a lot more developers working on pyramid, and the set of libraries extending up around it than Pylons managed in the first several years of existence. I really believe that before long, there'll be a set of such compelling libraries for use with pyramid, this issue will be a non-starter, and you'll have a great case to make for clients on why they should port that wasn't nearly as easy to make for moving from Pylons 0.9.6 -> 1.0. Cheers, Ben -- 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.
