[Product-Developers] Re: Where does it hurt?

Martin Aspeli optilude at gmx.net
Sun May 18 13:24:26 UTC 2008

Hi Michael,

This is great - thanks a lot!

Michael Hierweck wrote:
> 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

Agree - we should document this better.

> * How to extend member profiles

Agree - we probably need better technology for this. membrane/remember 
is good for one problem domain, but isn't really appropriate IMHO for 
simple "I just want to add some fields". Chapter 13 in my book does 
cover this, but it'd be nice to have automated forms and better control 
over the schema. I believe Kapil's ore.member does this, by the way.

> * How to scale related to a large amount of content (still not clear for
>  me)

To a certain extent, scalability to huge deployments (hundreds of 
gigabytes or thousands of logged-in users) will always require some 
careful design and trade-offs. I think if you understand CacheFu, 
Varnish and ZEO, you're pretty well covered until you reach those sizes, 
though. ZODB blob support (which will come "for free" with the next 
version of ZODB) is another important step, but shouldn't have much 
impact on users.

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

I'm glad to hear that.

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

I'd say, "use Archetypes".

Like Wichert say, we can't *not* do the R&D and discuss how the future 
may look, but that doesn't mean you should think that what has worked 
for the last several years is suddenly dead.

plone.app.content works now, but I'd only recommend it for lightweight 
objects that are less about full-blown content and more about capturing 
some data. There's nothing p.a.c can do right now that Archetypes can't 
(and plenty that AT can do that p.a.c can't), but if you are working on 
something and you feel that AT is getting in your way, it may be worth a 

To me, p.a.c today is a building block for bigger and better things that 
are still in the R&D phase.

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

formlib is tried and tested and works well. Hacking AT widgets is 
probably more pain that it's worth. z3c.form has a lot of promise, and 
is in many ways an incremental evolution of formlib (at least for the 
use cases where formlib is appropriate).

> * Skinning
> Zope 2 vs. Zope 3 technologies

Yes - this is probably the top of my list to unify (and also very hard).

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

Yes. I think the standard way will be that a schema is an interface with 
zope.schema fields and that longer term, atapi.Schema will be a shim 
around this, but that's very tentative and speculative at this point.

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

Spot on. This is pretty much the reason why most efforts to improve this 
aspect of Plone assume that we will design a cleaner solution based on 
simpler components and then retrofit them into AT at a future stage 
(which is of course the same approach that the Zope 2 -> Zope 3 
evolution is taking)

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

See above. Note that there are a few efforts ongoing currently about 
making things like Xapian and Lucene easier to work with for indexing 
huge sites.

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

Managing the body of documentation is a huge problem, for the simple 
reason that it requires more manpower than we have able volunteers.

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

Yes, we should be a bit better at this.

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

I assume you mean "shouldn't be too different". I think everyone agrees 
with this approach.


Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

More information about the Product-Developers mailing list