On Jul 18, 2009, at 1:12 PM, Iain Duncan wrote: > 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'
The paradigm works well for various CMS oriented apps. I think both styles are useful which is why Pypes runs with Routes and traversal fall-back (or at least thats the intention). > Well, Mochikit does what Bob wanted, and then he stopped furthering > it. > Which is his right of course, but means that to anyone who has to > justify their platforms to less educated decision makers, it's > impossible to advocate for something that is perceived as no longer > active. So while I really liked Mochikit, I certainly can't convince > anyone that we should be using it. Well, when it comes to work, Pylons as is does what I want. Large company rich webapps don't benefit so much from some of the features I'm looking for when I develop smaller websites with various bits, like my new blog, or the PylonsHQ site. So for my own other various things, I need better pluggability, one of the things Pypes helps resolve in addition to bringing repoze and Pylons together. So I'm definitely still working on moving things forward, but Pylons 1.0 will be mostly 'done' as Mike Orr mentioned. While Pypes will most likely be the future with backwards compatible layers to help people transition. Pylons has always been about legacy support and helping users migrate, even in pre-1.0, and will continue to be oriented to making it easier to maintain and migrate older apps. > 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 think the fact that Pylons cared about supporting existing apps enough to have 1/3rd of its pre-1.0 code-base be legacy support and deprecation warnings (while Django pre-1.0 just tossed things in svn with no warnings, etc.) should speak volumes about caring about business customers. Legacy apps happen everywhere when the code-base gets huge, and moving forward becomes more problematic. Given the rate of changes in Django, I'd be more nervous about supporting a 2-year old Django app, than a 2-year old Pylons app. 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 -~----------~----~----~----~------~----~------~--~---
