[Product-Developers] Plone Developer Cheatsheet (Was: Re: Where does
gmane at dylanjay.com
Thu May 29 00:18:37 UTC 2008
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
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.
More information about the Product-Developers