[Repoze-dev] bfg- Routes...
Just a heads up. BFG currently uses Routes (http://routes.groovie.org) to do URL pattern matching. While fleshing out URL generation and matching support for BFG "url dispatch", I've come to the conclusion that it's probably a better long-term strategy to just write some simple regex generation stuff (maybe stolen from bobo) than to continue to use Routes to match and generate URLs. The set of assumptions that Routes makes isn't entirely appropriate for BFG, and I've found the workarounds to those assumptions make the code fragile and complicated. I'll try to not change things very much with respect to the actual pattern matching syntax, but I'm probably not going to release a 1.0 until BFG doesn't have a Routes dependency. The syntax may need to change a bit too, to ease implementation. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg- Routes...
On Wed, 2009-06-24 at 04:09 -0400, Chris McDonough wrote: > Just a heads up. > > BFG currently uses Routes (http://routes.groovie.org) to do URL pattern > matching. > > While fleshing out URL generation and matching support for BFG "url > dispatch", > I've come to the conclusion that it's probably a better long-term strategy to > just write some simple regex generation stuff (maybe stolen from bobo) than > to > continue to use Routes to match and generate URLs. The set of assumptions > that > Routes makes isn't entirely appropriate for BFG, and I've found the > workarounds > to those assumptions make the code fragile and complicated. > > I'll try to not change things very much with respect to the actual pattern > matching syntax, but I'm probably not going to release a 1.0 until BFG > doesn't > have a Routes dependency. The syntax may need to change a bit too, to ease > implementation. > Just a thought from the sidelines, is there not also an advantage from a marketing perspective to sharing some of the pylons components? Does routes really need to be ditched to do what you want? For me personally (admittedly a totally new user to zope/repoze) it's a negative to have bfg moving to share fewer components with Pylons, as one of the main attractions to me of bfg is it's complementary nature to pylons. And conversely, one of the turn offs for me re Django as the rampant not-invented-here aspect. my 2 cents to be taken with much salt, iain ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg- Routes...
2009/6/25 Iain Duncan : > For me personally (admittedly a totally new user to zope/repoze) it's a > negative to have bfg moving to share fewer components with Pylons, as > one of the main attractions to me of bfg is it's complementary nature to > pylons. And conversely, one of the turn offs for me re Django as the > rampant not-invented-here aspect. Perhaps what Chris is cooking up could be split up into a separate package; it seems to me that the motivation is that the Routes implementation could be improved upon, both in terms of performance and code quality. I could be wrong. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg- Routes...
On 6/25/09 5:35 AM, Iain Duncan wrote: > On Wed, 2009-06-24 at 04:09 -0400, Chris McDonough wrote: >> Just a heads up. >> >> BFG currently uses Routes (http://routes.groovie.org) to do URL pattern >> matching. >> >> While fleshing out URL generation and matching support for BFG "url >> dispatch", >> I've come to the conclusion that it's probably a better long-term strategy to >> just write some simple regex generation stuff (maybe stolen from bobo) than >> to >> continue to use Routes to match and generate URLs. The set of assumptions >> that >> Routes makes isn't entirely appropriate for BFG, and I've found the >> workarounds >> to those assumptions make the code fragile and complicated. >> >> I'll try to not change things very much with respect to the actual pattern >> matching syntax, but I'm probably not going to release a 1.0 until BFG >> doesn't >> have a Routes dependency. The syntax may need to change a bit too, to ease >> implementation. >> > > Just a thought from the sidelines, is there not also an advantage from a > marketing perspective to sharing some of the pylons components? Does > routes really need to be ditched to do what you want? > > For me personally (admittedly a totally new user to zope/repoze) it's a > negative to have bfg moving to share fewer components with Pylons, as > one of the main attractions to me of bfg is it's complementary nature to > pylons. And conversely, one of the turn offs for me re Django as the > rampant not-invented-here aspect. Hi Iain, Thanks for the comments! BFG needed Routes to do two things: 1) parse a URL and turn it into a match dictionary and 2) generate a URL when asked for. The main reason for disusing Routes is that, for BFG, it a) made too many assumptions and b) just does too much. Routes made a bunch of assumptions about how it was going to be used that were not true for BFG. For example, it assumed that "controllers" and "actions" are used (neither concept exists in BFG), that it should scan a directory to find controllers (it shouldn't). We worked around this for some time successfully. It also just plain did too much: it provide facilities for REST resources, that it should help to do redirection, that it should provide middleware, and so on. It made heavy use of thread locals. We used none of that stuff, but we worked around it. But the thing that finally made me remove it was that the "url_for" API and equivalents don't match my expectations about how the world works. In particular, when you use it, you can't generate a URL that has a replacement value with the same name as a query string element. And that's a limiting assumption I don't want to bake into BFG, for better or worse. It doesn't seem to bug the Pylons folks, but I'm a bit picky I guess. I considered rewriting the URLGenerator class that ships as part of the routes "utils" package to make this possible. I probably would have needed to maintain this URLGenerator fork *inside* BFG, because it's just not an issue for the Pylons folks. The URLGenerator relies on the Route Mapper and Route API staying stable, but the API is not documented. So even doing that would have been a gamble; when upgrading Routes, BFG URL generation would have high odds of breaking. I agree that, when possible, we shouldn't invent things in favor of just reusing them. That's why we used Routes originally. OTOH, using something just for the sake of fidelity with some other system isn't really a goal in BFG. Traditionally, once we've reached the limits of a library's usefulness and appropriateness, and the change we require to make it useful would disrupt some other system (Pylons) or require a long technopolitical beseechment to the library author about why what we want is "the right thing", we just replace it, as long as replacing it is easy.In this case, it was. The Routes package is about 1400 lines of code in total. I didn't understand it all. The code that replaced it was about 50 lines, and I do understand them all. FTR, I'm not really picking on Routes or Pylons: we've disused many Zope components also in the same way. For example, we wrote "repoze.zcml" to allow us to use ZCML without needing ten or so other packages that were unrelated to the operation of BFG. The same sorts of issues were raised at the time, but at the end of the day, it was the right thing (BFG runs on GAE, for instance, because it has no dependency on any C extensions). So I guess I'm asking for the same sort of trust a consultant might ask from a client wrt to choices made to use or not use a particular library in BFG: if the client picks the tools the consultant should use, odds are that the outcome won't be quite as good as if the client allowed the consultant to pick his own tools. Thanks, - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] bfg- Routes...
On Thu, 2009-06-25 at 12:32 -0400, Chris McDonough wrote: > On 6/25/09 5:35 AM, Iain Duncan wrote: > > On Wed, 2009-06-24 at 04:09 -0400, Chris McDonough wrote: > >> Just a heads up. > >> > >> BFG currently uses Routes (http://routes.groovie.org) to do URL pattern > >> matching. > >> > >> While fleshing out URL generation and matching support for BFG "url > >> dispatch", > >> I've come to the conclusion that it's probably a better long-term strategy > >> to > >> just write some simple regex generation stuff (maybe stolen from bobo) > >> than to > >> continue to use Routes to match and generate URLs. The set of assumptions > >> that > >> Routes makes isn't entirely appropriate for BFG, and I've found the > >> workarounds > >> to those assumptions make the code fragile and complicated. > >> > >> I'll try to not change things very much with respect to the actual pattern > >> matching syntax, but I'm probably not going to release a 1.0 until BFG > >> doesn't > >> have a Routes dependency. The syntax may need to change a bit too, to ease > >> implementation. > >> > > > > Just a thought from the sidelines, is there not also an advantage from a > > marketing perspective to sharing some of the pylons components? Does > > routes really need to be ditched to do what you want? > > > > For me personally (admittedly a totally new user to zope/repoze) it's a > > negative to have bfg moving to share fewer components with Pylons, as > > one of the main attractions to me of bfg is it's complementary nature to > > pylons. And conversely, one of the turn offs for me re Django as the > > rampant not-invented-here aspect. > > Hi Iain, > > Thanks for the comments! > > BFG needed Routes to do two things: 1) parse a URL and turn it into a match > dictionary and 2) generate a URL when asked for. The main reason for > disusing > Routes is that, for BFG, it a) made too many assumptions and b) just does too > much. > > Routes made a bunch of assumptions about how it was going to be used that > were > not true for BFG. For example, it assumed that "controllers" and "actions" > are > used (neither concept exists in BFG), that it should scan a directory to find > controllers (it shouldn't). We worked around this for some time successfully. > > It also just plain did too much: it provide facilities for REST resources, > that > it should help to do redirection, that it should provide middleware, and so > on. > It made heavy use of thread locals. We used none of that stuff, but we > worked > around it. > > But the thing that finally made me remove it was that the "url_for" API and > equivalents don't match my expectations about how the world works. In > particular, when you use it, you can't generate a URL that has a replacement > value with the same name as a query string element. And that's a limiting > assumption I don't want to bake into BFG, for better or worse. It doesn't > seem > to bug the Pylons folks, but I'm a bit picky I guess. > > I considered rewriting the URLGenerator class that ships as part of the > routes > "utils" package to make this possible. I probably would have needed to > maintain > this URLGenerator fork *inside* BFG, because it's just not an issue for the > Pylons folks. The URLGenerator relies on the Route Mapper and Route API > staying > stable, but the API is not documented. So even doing that would have been a > gamble; when upgrading Routes, BFG URL generation would have high odds of > breaking. > > I agree that, when possible, we shouldn't invent things in favor of just > reusing > them. That's why we used Routes originally. OTOH, using something just for > the > sake of fidelity with some other system isn't really a goal in BFG. > Traditionally, once we've reached the limits of a library's usefulness and > appropriateness, and the change we require to make it useful would disrupt > some > other system (Pylons) or require a long technopolitical beseechment to the > library author about why what we want is "the right thing", we just replace > it, > as long as replacing it is easy.In this case, it was. The Routes package > is > about 1400 lines of code in total. I didn't understand it all. The code that > replaced it was about 50 lines, and I do understand them all. > > FTR, I'm not really picking on Routes or Pylons: we've disused many Zope > components also in the same way. For example, we wrote "repoze.zcml" to > allow > us to use ZCML without needing ten or so other packages that were unrelated > to > the operation of BFG. The same sorts of issues were raised at the time, but > at > the end of the day, it was the right thing (BFG runs on GAE, for instance, > because it has no dependency on any C extensions). > > So I guess I'm asking for the same sort of trust a consultant might ask from > a > client wrt to choices made to use or not use a particular library in BFG: if > the > client picks the tools the consult
Re: [Repoze-dev] bfg- Routes...
On Thu, 2009-06-25 at 11:56 +0200, Malthe Borch wrote: > 2009/6/25 Iain Duncan : > > For me personally (admittedly a totally new user to zope/repoze) it's a > > negative to have bfg moving to share fewer components with Pylons, as > > one of the main attractions to me of bfg is it's complementary nature to > > pylons. And conversely, one of the turn offs for me re Django as the > > rampant not-invented-here aspect. > > Perhaps what Chris is cooking up could be split up into a separate > package; it seems to me that the motivation is that the Routes > implementation could be improved upon, both in terms of performance > and code quality. I could be wrong. That's an intriguing possibility. I've been working on a wsgi-only admin app and was trying to figure out how to do the dispatching. Reading the repoze docs, I think the way I was imagining the design to flesh it out is somewhere between pylons-routes controllers and zope style traversal to views. This dispatch tool might be very useful for such a scenario. Or I may just do the thing in repoze and drop it into pylons projects, lots of reading to do first. Anyway, great mailing list and tutorials. Iain ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
