Martijn Faassen wrote:
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
