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)
_______________________________________________
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
