[Product-Developers] Re: Where does it hurt?
optilude at gmx.net
Sun May 18 15:20:17 UTC 2008
Wichert Akkerman wrote:
> Previously Martin Aspeli wrote:
>> 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.
> 90% of the times someone asks for this the correct answer is simply 'add
> properties in portal_memberdata', which has been working for years. For
> the common case I still remain unconvinced we need remember, membrane,
> ore.member or something else..
I agree, although I think we should support join forms and profile edit
forms that grow to support custom member data. Having a schema from
which to compose and render forms makes sense to me. I haven't used
ore.member, but it was my understanding that this is all it does.
>> To me, p.a.c today is a building block for bigger and better things that
>> are still in the R&D phase.
> I'ld call it an experimental prototype. You can do things with it, but
> we may just as well replace it with something else.
I think we're more likely to build something on it than replace it
outright, because the base classes in plone.app.content are really just
convenience starting points that pull the bits of Zope 2, 3 and CMF that
you need to make a content type that's meaningful to Plone. I certainly
see the mix here evolving a bit, and I'd love to shed some of the
zillion base classes, but having such a shared starting point that more
specific technologies can build upon makes a lot of sense to me.
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