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. >> For how long? Five years, ten years, twenty years? I have a bit of a >> problem with the idea that the developers should support it "forever". >> ... >> If the developers were to lose interest in Pylons today, there would >> still be Pylons apps running in five years which the developers should >> support. In ten years there may or may not be a few apps still >> running, but whether it's reasonable to expect support then is >> debatable. Twenty years is meaningless in Internet-time because the >> potential for paradigm shift is so great; there may not be any "web >> apps" by then. > > Ah, I agree, but developers would have a hell of a time convincing > clients that developing on Pylons is good for the clients business, > because the developers are suddenly much harder to replace. For the > client, that's pretty important. I have discovered this with my legacy > TG1 apps, and it's not a fun position to be in for anyone. If Pylons > continues to grow but in accordance to their vision, that won't happen. > It doesn't need to be a big vision, but it can't just stop... I guess the website just needs to say something like, "Pylons will be supported for at least the next N years even if R&D leads to a new framework in the meantime." But how do you word that without scaring people away? Python has gone through a difficult three years from the incompatible pre-WSGI frameworks, to the current situation where they all support WSGI and are looking for the next step. TG1 was perhaps a casualty of this transition because it innovated many enduring ideas but their first implementations weren't great. Essentially, TG1 pioneered the mistakes that helped Pylons and TG2 avoid those mistakes (non-WSGI foundation, rigidly supporting only the default libraries, not considering the libraries' long-term prospects, etc). It was already clear before TG1 was out that it was a dead end, and that put the developers in the difficult situation of promoting a dodo. But they had to finish it to give its aspiring users something complete, and to avoid losing them all before TG2 was ready. I suppose TG1's fate is a warning to Pylons, but I also think the situation is not nearly as stark. Routes and FormEncode aren't going anywhere, and they were built for long-term maintenance even if future versions evolve or something supercedes them. Pylons' minimalism ensures that the dependencies are easy to maintain. The biggest fragility in Pylons (the magic globals) is well known, and even they require only a small amount of developer work periodically to keep them functioning in new situations. All Python frameworks are converging (even if Django and Twisted are doing so more slowly), which makes it increasingly easy for a Python programmer to work on any framework. So the "developers hard to replace" may be more of a perception problem than actual. I do see the other side. "Boo hoo, our application's framework is unsupported, we can't attract progammers willing to maintain it, and why is it our responsibility to switch frameworks every few years?" But if you take that too far you stifle innovation, and then everybody loses. Python's transition was difficult but necessary. Now we're in a much better situation, and we (users) can adopt changes more leisurely, because both the new and the recent-past software have a viable future and are easier to maintain than their predecesors. -- Mike Orr <[email protected]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
