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 me) (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 risk.) > - 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. Suggestions: * 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. HTH Michael _______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
