[Product-Developers] Where does it hurt?

Michael Hierweck team at edv-serviceteam.net
Sun May 18 12:14:20 UTC 2008

Hi Martin,

Martin Aspeli wrote:
>  - Areas where there's insufficient/poor documentation, but once you
> learn how to do something, it's clear how to proceed.

* How Plone make use of underlying technologies
* How to extend member profiles
* How to scale related to a large amount of content (still not clear for

(Your Plone 3 book has improved to situation and in the meantime there
is much additional documentation about Plone 3 online. Documentation is
often some steps beyond the technologie. In general it's much better
than some years ago.)

>  - Areas where there appears to be more than one approach, and it's not
> clear which one to choose

* Persistence:
Archetypes vs. plone.app.content vs. Devilstick vs. collective.tin

* Standalone Forms:
AT Widgets "Hack" vs. zope.formlib vs. z3c.form

* Skinning
Zope 2 vs. Zope 3 technologies

(Main problems: you need to know all approaches to decide. Knowlegde is
approch specific to a higly grade. Knowledge is sometimes
outdating/superceeding fast. You never know which approaches a future
proof, especially related to non core (= collective) components => high

>  - Areas where Plone doesn't appear to have a good way to do something

Different widget/schema technologies for add/edit forms and standalone
forms, escpecially atapi.Schema vs. zope.schema.

Archetypes make it hard to separate between interfaces and
implementation. Classes based on Archetypes are always complex and don't
fit in a world of "orchestrating small pieces of software". Complex base
and mix-in classes make debugging/profiling hard.

Performance, especially related to indexing. (ZEO helps scaling towards
large amounts of page impressions/vistors. Improve handling of huge
amounts of content objects.)

> 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.


* Documentation/Tutorials should not only say what they are doing, but
also why they are doing it this way. (Many do.) Documentation marked as
outdatet should tell what aspects are outdated. (Often this is related
to small pieces only, e.g. defining s.th. in now done using GS.)

* Keep the official roadmap up to date and let the people use this to
decide which technologies are future proof and which are not.

* Try include performance related improvements into the core
(QueueCatalog, collective.indexing) as every site out there should
benefit from performance.

* Keep in mind, reusing technologies where sensibly possible,
is developer friendly, e.g. zope.schema + z3c.form might be used on
ZODB, RDBMS content and standalone forms. The persistence layers for
RDBMS and ZODB should be too different.



More information about the Product-Developers mailing list