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
> 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
> not true for BFG. For example, it assumed that "controllers" and "actions"
> 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,
> it should help to do redirection, that it should provide middleware, and so
> 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
> 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
> "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
> 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
> 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
> us to use ZCML without needing ten or so other packages that were unrelated
> the operation of BFG. The same sorts of issues were raised at the time, but
> 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
> 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
Makes sense to me, thanks for the explanation.
Repoze-dev mailing list