Hi all,

First of all, a couple of apologies: for the cross-post, but I think this concerns all these groups; for my ignorance: I'm only starting to scratch the surface of Z3, via Five, coming from Plone; and for dragging this out again. However, I think this is important.; and maybe for the length. :)

As open source developers, we are dependent on an influx of new talent. That talent starts when people get interested in our products. I got a whiff of Plone for a project, played with it, loved it, learnt about it, and before I knew it, I was a core developer. If ever I have the chance to help out Z3-core, it'll be by way of this path, too, and there are many like me.

However, the initial hurdle is quite steep. I really liked the Z2 way when I first learnt about it, and I love the Z3 way even more now that I'm digging into it. But Zope uses obscure technologies that no-one's heard of, no matter how good they are. Hence, anything to lower the burden of entry should be viewed as important, but it's all too easy for those of us who once climbed the hill to be excited by ever-better ways of doing things that we sometimes forget what the learning curve was like. I'm already trying to formulate how we can document to new Plone developers how to take advantage of the Z3 component architecture via Five, and explaining the mind-bend required to think in terms of adapters is actually not so simple. :) But I digress.

I think for a lot of people, what drew them to Plone and then Zope-based development was to ease with which one could re-use and override elements of the application, especially the UI. Take a look at http://plone.org/documentation/how-to and see how many of the user-contributed documents are from people who say "I'm not an expert, but I figured out ..." and then go on to talk about portal_skins/custom. Ideally, we'd like to make everything people want to do available with a nice UI, but this is unrealistic. The things people write about in those how-tos are the things real users want to do, and they find low-impedance ways of achieving them with through-the-web customisation.

So, when my customer wants a portlet, he discovers that he can copy-and-paste an example he saw on the web into his browser and edit a text box in the ZMI, and suddenly he has his portlet. Okay, that scares me a bit, but it's actually really important. If he had to go to the filesystem, set up a folder with some arbitrary structure, enter some boilerplate python code, remember to name files __init__.py and make a crazy configure.zcml with funny angle brackets, well, frankly, I think he wouldn't bother. More work for me, perhaps, but he could just as easily have been the next optilude, learning, tinkering, testing, exploring and finally contributing something valuable.

The arugments against TTW, at least in its CMF 1.x form with portal_skins/custom or, worse still, page templates scattered through a content structure with acquisition magic, are clear. But that doesn't mean the concept isn't valuable.

The thing that scares me is that as we move to use more Five/Z3 Views in Plone, those templates stop being customisable through the web. And the more obscure and complicated it becomes for a new user just to change a minor element that can't be fixed with CSS etc. or some setting in the UI, the more likely that user is to give up.

I think there needs to be a solution for making quick, preferably TTW customisation of UI templates. As Tres pointed out, this shouldn't add a performance overhead and lead to maintenance woes for those who know what they're doing. Ideally, the site admin should be able to switch this off. Or even, the view creator should have to turn it on (e.g. by using a ZCML directive that makes a template TTW customisable. Or something). I know this strays away from best practice, that people will slap in crazy python: statements in TAL etc. Having a way of dumping this stuff to "real" views would be good, even necessary. But I think ignoring these users because the approach that's most accessible to them doesn't fit with the purity of our framework will seem to them elitist, and it'll probably drive more people to ruby-on-rails, who sell themselves on how easy it is to get started.

I don't know how this may work, or whether it should sit in the Z3, CMF2 or Plone 2.x layer of the stack. My hunch is CMF, but I'd like to challenge those more in the know to explain how Z3/CMF/Plone can still accomodate these users, without hurting the more seasoned developers at the same time.

Thank you,


Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to