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 Repozeemail@example.com http://lists.repoze.org/listinfo/repoze-dev