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.


Repoze-dev mailing list

Reply via email to