I've sighed a few times the last months when I ran into more and more Python-based schema and form frameworks. I developed Formulator for Zope 2 pretty early on, and was involved in 2002 in setting up Zope 3's schema framework, so I've contributed to the problem. In the Zope world there's also Archetypes, and I heard Archetypes is now working on a new generation which redesigns everything.. And I ran into Schevo and I saw formencode, which both have a history too, and then finally what made me sigh was running into a weblog post by Philip Eby on Spike. It all looks all very cool, but how many more do we need here?
I believe that what we, framework developers, need is a bit more humility ("We're open, you just all plug into our great solution!" is not humble), and more active outreach to include pieces of other frameworks. While we also need to do a bit of work of opening up the neat bits of our frameworks to reuse by others, but that rather easily turns into the non-humble "Use mine!", so I think what we really need to do more of is the "Let's look for something to reuse!" variety of outreach than the "look, I made mine real great!" outreach (we'll do the latter automatically anyway :). I think Ian Bicking has been saying similar things.
Well, since I show up in both paragraphs (having written FormEncode), and both sides of the issue, I guess I should reflect on why.
The duplication of work did occur to me (and I was looking to give up at one time: http://blog.ianbicking.org/where-next-for-formencode.html). And I realized that I was spread too thin to give the necessary attention to all my still independently-developed projects. The resolution of such a situation can go a couple ways -- I abandon the project entirely, I somehow get other developers involved, or I try to fold the ideas into someone else's project. All three are very difficult, some in practical ways (how to get other people interested, how to find a compatible project) some emotionally (abandoning code, or the humility required to abandon code *and* work on someone else's project).
I've gone through all three processes at times too -- FormEncode went dormant for a long time, then I kind of reminded myself of what it was useful for, then I looked around for other similar projects -- but I had no idea what to do once I found them. Say "hey, stop using what you are using, I got some better ideas"? I feel like an interloper. What I'm doing might apply to Archetypes or Zope schemas, but I'm not involved or invested *at all* with those projects, so my connection is tenuous. I feel like we have to meet in the middle somewhere, some neutral ground where people can be equally invested and involved... but I'm not sure how to do that, because what seems like a Big and Difficult Problem to me (form generation) may seem (at least at the moment) to be incidental to another project; useful, but not worth the coordination effort. Not to mention, what I think is important and distinguishing isn't what other people feel is important. (The other direction I considered was documentation: http://blog.ianbicking.org/a-theory-on-form-toolkits.html -- but is documenting a design aimed at decoupling that different than distributing the code that informed that design?)
I need to figure this out, because WSGIKit is in the same position -- I'm trying to factor out something that I think deserves to be shared among projects, but how to I get other developers to adopt the project or participate in the development? Make It And They Will Come isn't that reliable.
I think people are comfortable letting projects Compete In The Marketplace, i.e., put a bunch of stuff out there and see what comes out on top. But in reality nothing comes out on top, and reimplementation is common -- especially with something that tends to be mixed with an object model, like form generation.
Everyone pretty much agrees that simple is better, but "simple" can be hard to define. Some projects -- Zope 3 in particular -- build up a bunch of new metaphors for programming, like adaptation, interfaces, utilities, and declarative glue. To a core Zope 3 developer these aren't complexity, they are fundamental ways of thinking about development. They are the prerequesites for understanding everything else. These prerequesites always exists -- I consider some level of OO understanding a foundation that I expect, and so I don't consider (many) OO techniques to be a sign of increased complexity. But for someone with only procedural experience this won't be the case. This is okay, because The World has agreed that OO is a fundamental concept. But there isn't a consensus on these new object models that people are working on, not even within the domain of the web.
-- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
