On Nov 1, 1:47 pm, Alice Bevan-McGregor <[email protected]> wrote: > 30KLoC in 149 modules a microframework does not make.
Perhaps that was mis-stated. It was referring to 'micro-framework' more in what is accomplished (or what is not done) during a request. Chris McDonough wrote a post covering this he called "What's it doing?" referring to how much a framework does during a request: http://plope.com/whatsitdoing2 The individual stats can be seen under each dir in results.txt here: http://svn.repoze.org/whatsitdoing/ BFG has become pyramid, and the numbers haven't changed. As can be seen from the numbers, the call-stack is much shorter than supposed 'micro-frameworks'. From my own run of it, WebCore comes in a little better than Pylons, but not as good as Django. So there's small as in LoC, and small as in, how many functions/calls actually run during a request. There's also small as in scope of the framework itself. > Especially when it re-implements template engine adaptors (alacarte) It's probably debatable on whether BFG existed before alacarte, and who re-implemented who... > , session handling (Beaker), pyramid has a session plug-point, and there's already a pyramid_beaker package to plug in Beaker sessions. there was no "re-implementation" of beaker http://github.com/Pylons/pyramid_beaker > configuration file parsing (PasteDeploy), PasteDeploy is still used for config file parsing, as is PasteScript for creating a project template > thread locals (Paste), I believe that is used from Paste, though Paste had those because back in the day we wanted threading.local and ppl still used Python pre-2.4. > has a large amount of authentication/authorization code to adapt > repoze.{who,what} (a package I recall people saying was a mistake to make > required for TG2.0), It doesn't adapt or use repoze.who/what. You could use repoze.who, or not. It has 250 LoC in the auth modules combined. > object dispatch (crank), It has a different scheme called traversal, which functions in a different manner to ensure there's a separation of URL resolution, from the actual code that will get called. The hard binding that object dispatch has between URL traversing and the method that is actually called was part of the reason BFG folks sought to split that up. By not having the URL bound so closely to the actual code (controller method) that is called, it becomes much easier to extend them from other packages allowing for a level of re-use that is currently unattainable by this method. > regex-based routing (Routes), As the author of Routes, I can't really blame pyramid for not using it. I spent a weekend doing some re-writing of Routes functionality, based on the implementation from pyramid, and easily replicated almost all of its functionality that I was considering for Routes 2 in about 160 lines of code... vs the thousand-plus in Routes. The implementation in pyramid is about 120 lines of code or so, and uses methods I wish I had done in Routes originally, this implementation was more or less copied from bobo. Would I have appreciated having some patches to Routes that cut down on all that crufty code? Sure, absolutely. But at the same time, if someone wants a quick Routes-like system and can write the functionality they need in literally a hundred lines of code... vs the behometh the Routes code-base is... its hard to blame them for not putting in the rather huge amount of effort it would've been to rewrite Routes to use that code. > static file serving (Paste), etc. pyramid's static view for static content does use Paste. > All of this needs testing and documentation, It all has 100% unit tests with documentation that unfortunately makes the TG and Pylons docs pale in comparison... http://docs.pylonshq.com/pyramid/dev/index.html > all of which would be more useful as reusable, and more importantly, optional > components. Maybe, maybe not. One thing I've noticed managing Routes, Beaker, and Pylons, is that sometimes people want to introduce a feature into Routes or Beaker, that adversely affects Pylons... and its hard to clearly say why it can't be done... since they're supposed to be separate projects. > Most are already available as reusable components. From the standpoint of a > template engine developer I have to write adapters for two widget systems, at > least one framework (probably more), and still have my own API to deal with. > As a framework user, if I want to use a templating engine that’s new -I- have > to write the adapters. The duplication of work is horrendous. They are now, they weren't at the time though. Writing a template adapter is easy, I'd be happy to kick one out for a missing template engine. Right now there's ones for Jinja2, and Mako. And maybe a few others floating about. > It’s one thing to decide that a Django-inspired framework design (everything > and the kitchen sink available with no dependancies) is the way to go, in > which case rigid structure and organization is necessary, another to want a > microframework base, and a third to have a modular best-of-breed framework. > Pyramid seems to me to be none of these, and has quite the intimidating > codebase. I agree the code-base is not oriented to being able to see the big picture of what its doing just by walking into it. I'm not sure how much that hurts/helps, as oddly enough the worst code-bases I've had (Routes) seems to get more ppl fixing it than Pylons does. I haven't had too much of a problem going through it, as it is well documented, but obviously I'm coming at it from the perspective of a framework developer myself. Cheers, Ben -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
