[Zope-CMF] Retaining ease of customisation

[Martin Aspeli]

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,
Martin

-- 
(muted)