[Zope-CMF] Re: The components of Archetypes
So, I think 1 and 2 aren't that far apart sometimes. I agree with this...and I think biggest wins are somewhere in between. I don't necessarily want a compatibility layer, I just want the declarative quality of AT to spit out something I could play with more sensibly using the z3 paradigm. And I want people to be able to get a feel for the power of the z3 way of doing things in small bitesize pieces. Once you can do this, tutorials and documentation make sense, because the investment require before getting a payoff is low. Additionally, I think sometimes doing some of 1 can be beneficial to 2. In particular, it may be worthwhile to start supporting Z3 widgets in Archetypes (I read somewhere that plone_schema makes this possible already? Cool!). In that case, it may make sense to adapt Archetypes to support them, in turn stimulating people to port their widgets, or write new widgets that way at least. That way, they get immediate functionality while doing the right thing for future development, and Z3 gets lots of cool new widgets. +100 There is alot of good stuff in AT, albeit not perfect and sometimes obscured by many man years of expedient cruft. Let's not throw the baby out with bath water just because it's been crying too much. This is an excellent opportunity to take what has work about AT and move it forward and deprecate what is not used or forgotten. -w ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: The components of Archetypes
On Mon, 09 Jan 2006 14:29:06 -, Rocky Burt <[EMAIL PROTECTED]> wrote: Hi all, Sorry about the cross post, but I thought this topic concerned CMF, Plone, and Archetypes equally. I had a discussion with Alec Mitchell recently where we talked about the components that made up Archetypes and what people have talked about regarding these components. 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 Having just read Philipp's excellent book, I too would like to get more into Zope 3-style development. However, my feeling is that trying to provide a compatability layer is not necessarily necessary (heh). I am only thinking out loud here, so you may yet prove me wrong. :) Archetypes is fairly lightweight, actually (do I hear chuckles?), from the developer perspective. Making an AT schema is a fairly mechanical process (cut-and-paste, macros in your editor, ArchGenXML) - it's very declarative. Taking my AT schema and making a Z3 schema for it would be trivial so long as Z3 schemas supported everything I needed. Then there's AT support machinery, like vocabularies and validators. Again, these are fairly self-contained and easy to port to a Zope 3 story. For the UI, we have page templates that could be ported to views, and actions and aliases that would probably be mvoed from dicts and lists to ZCML. Again, this is very declarative. Then, I may have all kinds of logic, either with custom mutators/accessors, or with methods on my class. Factoring that out into adapters is again not rocket science. My point is that for the end-user, the base use case for Archetypes is pretty simple. If you had the time, you could write a script that read an AT product and spat out a Z3 one (in theory, I know it's harder than that). Where things get complex is where people do crazier things - custom storages, rummagings with AT's internals. So I see two options: 1. Try to evolve Archetypes from the current model into a more modern Z3 one. 2. Try to document how to do things people are used to do with Archetypes with Z3, cataloging patterns and best-practice, and at the same time factor things out of Archetypes that are missing in the pure Z3 world in such a way that they may be usable there. I'm leaning heavily towards 2. The current 1.x series of Archetypes has a long shelf life still, there's LOADS of code out there depending on it, including Plone's ATContentTypes. I think that trying to do a compatability layer to a complex and less-than-perfectly documented piece of software *and* move to a completely different design metaphor is rather ambitious. As a product developer, I'd probably rather gradually migrate my projects to a new metaphor when I'm ready than be forced to do so by the framework (upgrade and yipes, it's all changed!). And I'd rather not trust a compatability/migration layer that only covers 80% of the cases. So I'd take some pain in rewriting some old products as and when it makes sense. For that to happen, there are three things we need: 1. Binary/ZODB compatability or migrations that are easy to work with. Make it easy for me to switch my AttributeStorage or AnnotationStorage or whatever else types to use Z3 schemas' storage. (Note that I'm trying to work on this story now with contentmigration and a "port" of the Z3 zope.app.generations framework to make sense for CMF sites; of course GenericSetup also plays a part here). 2. A suite of components that make the Z3 story as powerful and featureful as Archetypes, such as a reference engine, a storage abstraction mechanism, a powerful validation mechanism, etc. This must be well-integrated and well-tested. In short, we need someone to champion this, to own it, and to manage what goes in and what isn't good enough. Without process, we're likely to repeat the mistakes of Archetypes. 3. DOCUMENTATION! We need to be much, much better than Archetypes was, at explaining the model, at explaining the API, at demonstrating best practice and at providing examples. Without it, no-one will make the switch and the effort will never manage to stay afloat. Martin -- (muted) ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: The components of Archetypes
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 - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: The components of Archetypes
thanks for starting up this conversation Rocky! I think these assertions are more or less deadon. The next step is charting a path for transition. for CMF, zope3 / five provides lighterweight analogs of AT features. What is currently lacking is a mapping layer to allow AT users to use the zope3 analog in a meaningful way within AT. As I've stated before, I think the process here is similar to how five gradually and systematically replaced functionality in zope2. Maintaining multiple content frameworks for CMF, z3 and AT is a waste of community effort, and I would like to see AT move toward being more of a glue library for components available to all. #1: Personally I believe there is too much boilerplate code required in building plain CMF types. This is the primary reason I find it convenient to use Archetypes, because a lot of that boilerplate code isnt' necessary. Its my opinion that CMF be refactored a bit to minimize this boilerplate in a similar fashion as to Archetypes has done it (which means Archetypes would no longer be any more convenient to build a type in). Bottom line: lets make CMF easier and more convenient to use z3 does a good job of reducing some of this boilderplate: it gives us dublin core and annotations. For obvious reason, it doesn't help much with factory type information. CMF is scheduled to move away from fti iirc, but some sort of localized "site" configuration of 'content types' is a basic requirement of any progeny of CMF. #2: Archetypes schema support has long provided plone developers with a way of defining (in a sensible style) the fields and types of fields created on a content type class. Personally I believe the automatic creation of mutators/accessors to be a negative thing, mentioning that explicit is always better than implicit. I think z3 schema's use of an interface to define accessors and mutators looks pretty good. But regardless, Zope 3 is providing similar support for all persistent objects. And since moving to Zope 3 development techniques is a strong goal of plone and cmf development, why not just build on top of that rather than continuing with our own AT based schema notion? Alec has the right idea here with his plone_schemas product. Bottom line: lets start working with Zope 3 schema's The issue is how to get there without maiming our developers(not an insurmountable problem, just something that needs to be faced). Some basic decoupling of the AT schema from the AT content object and decoupling of the different facets of the schema(View, Marshalling, Storage, Model, etc) are necessary to get there. here is a rough list of steps I see to move toward convergence: 1. return schema and schemata by interface rather than attribute access 2. make at wigets, fields, and validation interchangeable with z3 widgets and fields 3. start deprecating features that impede convergence: auto-generated mutators and accessors, etc 4. deprecate widgets, storage, marshalling, etc in the schema. Move the declaration of this behavior elsewhere. The AT schema is really a system for configuration and we should treat it like that, whether it be treating old schemas inclusion of view data and storage as default options, or moving schema operations to paradigms configurable by zcml. #3: Widgets is one area where development outside Archetypes has flourished. There has been a plethora of third-party widgets developed that people reuse. Zope 3 also has a widget mechanism and following the thought as in #2 ultimately this is the direction we're moving in. The problem of course at the moment is that Archetypes widget library is quite a bit more diverse than zope 3's widget library so there would definitely need to be some work porting the widgets from AT to zope 3 (plone_schemas also lets you use z3 widgets today). Bottom line: lets start migrating AT widgets to Zope 3 and use existing Zope 3 widgets today see above #4: There has been many a discussion regarding this item. Most people talk about separating out the references engine from Archetypes into its own product. As a primary goal this should allow any CMF based content type to participate in the references logic and not just ones built on Archetypes. Bottom line: lets move the references engine out of AT and into its own product I think this is a prime target and if people are interested in tackling this, I would like to work on it at the snow sprint. see next email ->> So what do you all think? In the CMF community, I know some (all?) of the CMF purists think Archetypes is generally unnecessary and adds a lot of bloat based on feedback I've received. AT is pretty unkempt compared to the likes of CMF or z3 and subject to the looser faster style of plone programmers. Breaking AT down into reusable components may improve adoption, since using some of AT wont necessarily mean you have to use the whole of AT; it will also force improvemen
