[Product-Developers] Plone Developer Cheatsheet (Was: Re: Where does it hurt?)

Dylan Jay gmane at dylanjay.com
Thu May 29 00:18:37 UTC 2008

Hi Guys

Following on from the "Where does it hurt?" discussion. I've come up 
with an idea that I think could help reduce the learning curve but I 
need your help.

I've created a Plone Developers Cheatsheet.

The idea is a complete list of what you need to learn reduced down to 
just best practice, not the extraneous stuff.

It's an open project and I like you all to be the first members and help 
get it to a suitably complete state that we can link it from plone.org 
documentation. It's very empty right now. Please be the first add and edit.

It's my hope that it becomes useful enough to each of us for keeping 
tabs on what what is best practice and whats the current best tutorial 
for something. At the same time remains simple enough to help guide a 
newbie developer into plone.

I fully expect that some decisions on what is best practice will be 
controversial. Hopefully this is a good place to record the results of 
those debates and perhaps the associated mailing list is good place to 
have those debates. or on here.

Also you can be brutally honest and tell me if you think this won't work 
and why.


Martin Aspeli wrote:
> Hi guys,
> Following a long discussion with Dylan Jay (buried in another thread on 
> Devilstick terminology), I thought I'd conduct an informal poll.
> ==> As a customiser of Plone, or as someone wanting to build bespoke 
> components that extend Plone, what do you find most confusing?
> I think this could fall into a few categories:
> - Areas where there's insufficient/poor documentation, but once you 
> learn how to do something, it's clear how to proceed.
> - Areas where there appears to be more than one approach, and it's not 
> clear which one to choose
> - Areas where Plone doesn't appear to have a good way to do something
> Please keep replies as succinct and factual as possible. I'm really not 
> interested in a winge fest by people who've been frustrated in the past. 
> I'd much rather have constructive feedback on where the pain is and, if 
> possible, suggestions for how to improve things.
> Cheers,
> Martin

More information about the Product-Developers mailing list