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 

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 
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 
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 
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 

I agree that, when possible, we shouldn't invent things in favor of just 
them.  That's why we used Routes originally.  OTOH, using something just for 
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 
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 
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 


- C
Repoze-dev mailing list

Reply via email to