Ian Bicking: the old part of his blog

Handling a diversity of frameworks comment 000

I know people are wary of frameworks, and I am too. But to clarify the discussion, "framework" can mean two things:

  1. A set of conventions.
  2. A library that tries to generalize logic.

The first is the natural result of dealing with a specific domain. This is why all web applications use a framework, even if it's a custom framework for the application. This set of conventions needs to be sufficient, as well -- the standard cgi module isn't sufficient, so if you use it you'll still end up creating a framework if your application is very large or general at all. And even that module is a mini-framework -- just not a very good mini-framework.

There's a real overhead to conventions, so if a framework is just (1) then it's still a problem. There's new words, new constructs, new interfaces, and those tend to infuse the code that uses a framework. If they don't, if those concepts are internal to the library, then it's not very framework-like. But it can't be helped sometime, you can only hope you use terminology that is clear, minimal (but sufficient), and maps well to the domain, and is conventional. Custom frameworks are most minimal, but least conventional, and tend to embody many nonconventional ideas of the application author.

The second -- generalizing logic -- is much more dangerous, though often just as necessary. For instance, if you didn't generalize logic a web application might start with:

if PATH_INFO.startswith('/contact'):
    import contact_form
elif PATH_INFO.startswith('/article') and PATH_INFO.endswith('/view'):
    import article_view

And so on. Because a simple thing like URL parsing is very logic-heavy. And if you use something like SimpleHTTPServer, you'll end up writing exactly that code. Or you'll end up writing code that imports modules and does path matching generally, moving that "code" into "data" (a URL mapping or an algorithm for resolving URLs). Then you've created your own logic-generalizing framework.

In this case you hope the framework is minimal and transparent, and follows several important rules (which I have in my head and somewhere on disk, but I haven't written down on this blog).

Paste has a little of both kinds of framework, and leaves a bunch up to frameworks that run on top of it. This causes problems, but I can only say that I think hard about the issues and I'm designing Paste with these issues in mind. Decoupling makes a framework more minimal, because it is locally-understandable, and Paste is all about decoupling. A common infrastructure encourages convention. And a wide base demands that the domain be well covered.

Comment on Re: Handling a Diversity of Frameworks
by Ian Bicking