Paul Everitt's comment on my previous entry regarding Plone 3's through-the-web story was a bit of an eye-opener for me. Paul says (emphasis mine):

I would love to hear the Plone core team say that TTW is an important, valid, and non-evil part of Plone, and encourage people to make that their entry point to casual customization.

TTW certainly has a reputation problem among core Plone (and presumeably Zope) developers and in that regard I have been guilty of that myself. I do see however -- for the first time in over four years, mind you! -- that there is nothing inherently evil about TTW. It's just that the Zope2 implementation of TTW customization is evil. But here's the kicker, of course: we're free to come up with something better ;-) Just as Zope has replaced Acquisition, Python Scripts and macros with more robust, elegant, sane and fun counterparts, we can do the same for TTW customization.

portal_view_customizations is certainly a step in the right direction. What it lacks IMHO is some sort of round tripping to the filesystem. What's really evil about TTW sofar is that you're basically pouring stuff into a one-way tunnel. What we need to do is come up with some method where TTW is (as Paul says) an entry point.

At this point the ball lies firmly in the court of the non-technical users ('the lamenters' so to speak). They need o come up with a TTW story that does not end with teir clients sinking code and templates into the ZODB. One idea that comes to mind is that perhaps the first time something is customized TTW, a default plone3_theme is created on the filesystem, complete with all the necessarty zcml bells and .cfg whistles. The customized code wouldn't be stored in the ZODB at all, but simply copied into files of that theme. This way anybody could start customizing with just one click and at any point somebody more technically inclined could simply commit the resulting filesystem code to a versioning repository.

Any takers?