Rocky Burt wrote: > 1) Ease of development - AT helps cut down on boilerplate code > as compared to building a regular CMF type (without AT) > > 2) Schema - The ability to declare which fields a content type has > and what "types" those fields are > > 3) Widgets - The ability to declare general purpose distributable > widgets that get displayed by default for either viewing a field > directly or viewed the editable version of a field > > 4) References - Being able to have a common framework that allows us > to relate one AT-based content type instance to another
I forgot a very important fifth component: 5) Storage layers - AT provides a standard way of having the storage of fields exist somewhere other than directly on the content type itself such as in a sql database. My opinion on #5 is: I think sqlos has a good approach to accomplishing another storage layer on standard z3 content types. At a minimum the AT storage layer mechanism should be broken out... possibly using the same sort of strategy as sqlos (although I think I'd still like to see something a little more transparent that does all field<->implementation mappings externally in zcml or something similiar) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net _______________________________________________ Zope-CMF maillist - [email protected] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
