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

Martin Aspeli optilude at gmx.net
Sun May 18 19:48:20 UTC 2008

Daniel Nouri wrote:
> Martin Aspeli writes:
>> Wichert Akkerman wrote:
>>>> 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.
> For simple content types, do we need something other than
> plone.app.content and a supporting form library?  (I had the impression
> that you're doing this in some projects already, Martin?) 

The efforts that are taking place (too slowly, alas) under the Dexterity 
banner are about this, yes. Dexterity will have other aspects too, such 
as XML-based and TTW schema building, for those who need/want this.

I see your z3c.form work to pull in the same direction, by the way.

> And wouldn't
> this approach, once it's proven to work well, tremendously simplify the
> story of developing with Plone?

That is indeed my hope.

> What are all these things that AT is supposed to have but p.a.c doesn't?

My list:

  - reference engine (plone.app.relations gives us most of that, but it 
needs to be more immediately usable and have proper widget support)

  - inline editing and validation (exists now with formlib, will 
probably require a z3c.form compatibility layer too)

  - better selection widget (uberselectionwidget needs to be completed)

  - file/image widgets, image scaling - maybe z3c.form has this?

  - transforms (plone.transforms will probably provide this)

  - version-on-edit (needs CMFEditions policy support)

  - staging (iterate needs to be generalised away from AT references)

  - support for standard metadata edit forms and fieldsets

  - field injection ala archetypes.schemaextender

  - multi-lingual support (plone.app.multilingual)

  - link integrity (plone.app.linkintegrity depends on AT references and 
field types)


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