[Product-Developers] Re: Plone Developer Cheatsheet

[Dylan Jay]

Daniel Nouri wrote:
> Dylan Jay writes:
> 
>> JoAnna Springsteen wrote:
>>> Short term, sure but incredibly valuable. And if it puts us in a place
>>> where we can talk about having best practices, then I think that's a
>>> great place to be.
>>> Having best practices gives us a much clearer path on what to
>>> document. In a sense, it's a baseline. You have this one way of doing
>>> something and this is the way to do it. Easier to document and
>>> maintain that then a million methods for accomplishing the same goal.
>>> And no, that doesn't mean we only do it that one way and we rule out
>>> other methods. Definitely don't want to do it. But a best practice
>>> helps us teach people where to start, what they really have to know,
>>> and generally gives them a good foundation once they move on to more
>>> complex things or pursue other methods.
>>> I could go on but my entire point is, it's a conversation worth having.
>> Thats certainly my intent behind it.
>>
>> First we'll see how if there is conflict and how it can be
>> resolved. I'll suspect it will need email notification of changes to
>> really make this work (and I don't think openplans does this) so
>> people can see when someone makes an update that others disagree
>> about. Or alternatively, encourage people to discuss before replacing
>> things on the best practices list.
> 
> So I started fiddling around with your document.  I have my little
> problem with putting z3c.form in "Not best practice".  If the argument
> is that it's "too early" let me tell you that my experience has shown
> that it's much more mature than zope.formlib.  If people who haven't
> looked at it decide that they don't want to learn it yet for whatever
> reason, they should call it "too early for me".

We have a problem in that formlib and z3c.form fill the same purpose. 
Since it's a current best practice list both can't exist in the same list.
Since formlib is need to create a portlet I figured it had to be in the 
list. I also figured it had only just been newly integrated into plone 
even if it's mature on z3.
Perhaps you should ask this list as a separate thread?

> Propse: Add a section "Forms", pull out PloneFormGen, zope.formlib and
> z3c.form out of the their current sections and put them all there, side

I got rid of those headings. Now just 3 sections. "Best Practice", 
"Depricated" and "Newer/Alternatives". Should be clearer what goes where.

> by side.  I don't like "Standalone forms" either, as neither
>  zope.formlib nor z3c.form specialize on "standalone forms", nor should
> their use within Plone be encouraged to be for standalone forms.

For plone best practice that is what they are good for, since AT is the 
currently the best practice for doing content types.

> I don't like the "Zope 3" section also.  While the underlying technology
> used comes from Zope 3, it's more useful to distinguish by "What is this
> useful for".  If people want to do content types, they don't care if
> it's Zope 3 or not; they want to know about content types (and
> e.g. Archetypes).

good point. got rid of the heading.

> Maybe these would be better sections: Python and Development tools,
> Templates and CSS, Installation/Infrastructure, Zope 3 Components,
> Content Types, Forms, etc.
> 
> If your argument is that newbies need to see what's essential and what
> not, why not mark items in the individual sections with "beginner",
> "advanced" and "expert"?

I've kind of change it to current, past and future.
The ordering within each section should hopefully reflect how advanced 
it is.
z3c.form for instance isn't advanced. apparently it's easier. but the 
question is, is it current best practice?

Also I took your reasons why X is better than Y out. The "Why" field was 
misleading. I renamed it to "For". The intention is a short sentence of 
what problem that technology or combination of technologies is there to 
solve. If it's a complicated problem then it should have a name and page 
of its own describing the problem.