On Sat, 27 Dec 2008 10:16:15 -0800, Ross Patterson <m...@rpatterson.net> wrote:

So I would like to see something of a slight-of-hand here.

Sleight. Just because I used to make the same mistake myself. ;)

Speaking of Dexterity:

Sleight, meaning dexterity or deceptiveness, comes from the Old Norse slœgð.[3] Sleight of hand is often mistakenly written as slight of hand. Slight descends from the Old Norse slettr, meaning plain, flat, even, smooth, level.


Sorry for the aside, I found it amusing and somewhat relevant, with the Old Norse (Martin ;) behind Dexterity, etc. :)

I think it's also important, however, that there be a *flavor* of Plone
that uses *only* the next generation of content type/schema definition
for those developers like myself that are eager to just move on.

Yup, the idea is to make AT *optional* (but still default), and to be able to supply a Dexterity-based alternative. Then we can work on the migration story from AT->Dexterity without that being a blocker for 4.0.

In other words, if you start a new project, you'll probably want to look into Dexterity-based types — if you have an existing site running Archetypes, you'll probably want to keep that for the time being. This means that developers that know what they are doing and/or new users could go with Dexterity immediately, whereas the people that mostly care about keeping their existing site running could stick with AT.

We might also choose to only support the new layout model with the new types, if this makes it easier to manage. We'll cross that bridge when we get there.

Of course this raises the concern of yet again running two different
technologies side-by-side.  To mitigate this, I'd be in favor of moving
very quickly to a 4.5 that completely removes AT as a part of
Plone-the-product at the very least.

This would have to be named Plone 5.0. Replacing the default types approach is a huge undertaking, especially from the upgrade side. If Plone 5.0 was a release that only did this change, I'd still be happy with it. :)

Alexander Limi · http://limi.net

Framework-Team mailing list

Reply via email to