[Product-Developers] Re: Plone Developer Cheatsheet
daniel.nouri at gmail.com
Thu May 29 16:50:17 UTC 2008
Thanks. I think the new structure is definitely an improvement.
It looks a bit overloaded though. There are 34 points in "Current best
practices" without apparent order. It's hard to find what you're
I believe what we want is a table of contents at the top, and one more
level of structure. I imagine something like:
- Current best practices
- Python and development tools
- Installation and Infrastructure
- Zope Component Architecture
- Templates and CSS
- Content Types
- Views and Forms
- Emerging best practices
- [maybe same as above, except that we leave out empty sections]
- Obsolete practices
When I start working with Plone, I can work through the Current best
practices from top to bottom, picking everything that's declared "must
read" (alternatively: "beginner"). And by reading the "advanced"
articles/links in "Templates and CSS" I can specialize in
skinning/theming. Relying on the implicit order of items for weight
isn't structured enough. Especially when you have more than one author.
Dylan Jay writes:
> 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?
You don't need formlib for Plone 3 style portlets, you can also use
There's still an argument for preferring formlib over z3c.form in this
document. And that's that Plone itself uses formlib. I think the
"Emerging best practices" cover this kind of thing pretty well.
(Compare with GS migration steps.)
>> 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
>> 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.
AT is best practice for portal types in the CMF sense. It's not best
practice for objects with a slimmer interface. Many products (like
CMFPlone) store objects in the ZODB that aren't subclassed from CMF
types or AT, think simple records, tools. For these simple objects it's
misleading to say that Archetypes should be considered for add and edit
forms. In the end, I'd argue that "standalone forms" is bad naming.
I'd use "forms libraries" and explain the details on when to use what.
>> 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.
More information about the Product-Developers