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