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
>> While fleshing out URL generation and matching support for BFG "url
>> 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
>> continue to use Routes to match and generate URLs. The set of assumptions
>> Routes makes isn't entirely appropriate for BFG, and I've found the
>> 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
>> have a Routes dependency. The syntax may need to change a bit too, to ease
> 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.
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
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
Repoze-dev mailing list