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 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. >
Makes sense to me, thanks for the explanation. Iain _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
