I am a bit concerned. The talk is that after 1.0, pylons will be "done". Why is this, necessarily?
My feeling is that any project that "stops", or just goes into maintenance mode, loses a good reason for people to currently adapt it. That is, while new versions and concepts can always give heartburn, folks want to feel that by adapting a technology like pylons, they are jumping on a train which for a "long" time will be at the "cutting edge". Just look at rails - it is a continually evolving entity (with definite incompatibilities between major versions). Yes, the point has been made that pylons itself is rather small and that its components themselves will evolve - but still, I think the issue of abandonware scaring off potential people remains. I am not familiar with pypes, but if certain features are lacking in pylons (which, of course, there are), why not propose a pylons 2.0 which would have those features added? Or is the approach so different that this wouldn't make sense? I, for one, would like to see pylons succeed - but to do this, it *must* continue to evolve, IMHO. David On Jul 18, 10:57 pm, Iain Duncan <[email protected]> wrote: > On Sat, 2009-07-18 at 19:27 -0700, Mike Orr wrote: > > On Sat, Jul 18, 2009 at 1:12 PM, Iain Duncan<[email protected]> wrote: > > > > On Sat, 2009-07-18 at 12:45 -0700, Mike Orr wrote: > > >> On Sat, Jul 18, 2009 at 12:25 PM, Iain Duncan<[email protected]> > > >> wrote: > > >> > I am very interested in the idea of having > > >> > something that supports both Pylons style and zope-traversal style as > > >> > I'm know finding cases where zope-style-traversal is really handy. > > > >> What does this mean, for the Zope-challenged? Pylons traversal is > > >> Routes plus the PylonsApp and base controller code beyond that. > > >> Repoze traversal is based on a configuration file? Or what makes it > > >> more useful in some cases? > > > > Um, I am certainly not the guy to explain it, but I highly recommend > > > Chris M's awesome docs on the bfg site. Basically the router walks an > > > heirarchy of model objects that find their children one-by-one instead > > > of parsing the whole url at once and then dispatching from the whole. > > > After working through Chris's docs I'm sold that he is right that each > > > one has use cases that are good fits. > > > > ie > > > app/pet/1/'edit' > > > - app object looks up and instantiates pet > > > - pet looks up and instantiates the pet with key 1 > > > - router passes this object to the view named 'edit' > > > Ah, the TurboGears style. (And twisted.web and Quixote and several > > other frameworks.) I favored that approach for several years (better > > than the servlet approach which preceded it), but now I like how > > Routes completely disassociates the URLs from the controller > > hierarchy. Nevertheless, it's an important strategy that's available > > in Pylons via TG2, and in Pypes. > > Well, it's a fair bit different than the TG1 style in how the objects > call find and relate to each other, though it does *look* like the TG1 > style from the url. But I really recommend reading Chris's docs, they > are a good read even if you don't think you'll use bfg! > > Iain --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
