Dexterity简介
Dexterity简介
http://www.315ok.org/blogfolder/287
http://www.315ok.org/logo.png
Dexterity简介
Dexterity简介
Dexterity是针对Archetype的不足，重新为Plone设计的内容类型架构。
Dexterity设计哲学和理念：
Reuse over reinventionAs far as possible, Dexterity should reuse components and technologies thatalready exist. More importantly, however, Dexterity should reuse concepts thatexist elsewhere. It should be easy to learn Dexterity by analogy, and to workwith Dexterity types using familiar APIs and techniques.Small over bigMega-frameworks be damned. Dexterity consists of a number of specialisedpackages, each of which is independently tested and reusable. Furthermore,packages should has as few dependencies as possible, and should declare theirdependencies explicitly. This helps keep the design clean and the codemanageable.Natural interaction over excessive generalityThe Dexterity design was driven by several use cases that express the way inwhich we want people to work with Dexterity. The end goal is to make it easyto get started, but also easy to progress from an initial prototype to acomplex set of types and associated behaviours through step-wise learning andnatural interaction patterns. Dexterity aims to consider its users - be theybusiness analysts, light integrators or Python developers, and be they new orexperienced - and cater to them explicitly with obvious, well-documented,natural interaction patterns.Real code over generated codeGenerated code is difficult to understand and difficult to debug when itdoesn't work as expected. There is rarely, if ever, any reason to scribblemethods or 'exec' strings of Python code.Zope 3 over Zope 2Although Dexterity does not pretend to work with non-CMF systems, as manycomponents as possible should work with plain Zope 3, and even where there aredependencies on Zope 2, CMF or Plone, they should - as far as is practical -follow Zope 3 techniques and best practices. Many operations (e.g. managingobjects in a folder, creating new objects or manipulating objects through adefined schema) are better designed in Zope 3 than they were in Zope 2.Zope concepts over new paradigmsWe want Dexterity to be "Zope-ish". Zope is a mature, well-designed (well,mostly) and battle tested platform. We do not want to invent brand newparadigms and techniques if we can help it.Automated testing over wishful thinking"Everything" should be covered by automated tests. Dexterity necessarily has alot of moving parts. Untested moving parts tend to come loose and fall onpeople's heads. Nobody likes that.
Dexterity设计哲学和理念：
- 可重用性优先于不断的创新
- 精细单一的功能优先于复杂的模块
- Create a "real" content type entirely through-the-web without having toknow programming.
- As a business user, create a schema using visual or through-the-web tools,and augment it with adapters, event handlers, and other Python code writtenon the filesystem by a Python programmer.
- Create content types in filesystem code quickly and easily, without losingthe ability to customise any aspect of the type and its operation later ifrequired.
- Support general "behaviours" that can be enabled on a custom type in adeclarative fashion. Behaviours can be things like title-to-id naming,support for locking or versioning, or sets of standard metadata withassociated UI elements.
- Easily package up and distribute content types defined through-the-web, onthe filesystem, or using a combination of the two.
Reuse over reinventionAs far as possible, Dexterity should reuse components and technologies thatalready exist. More importantly, however, Dexterity should reuse concepts thatexist elsewhere. It should be easy to learn Dexterity by analogy, and to workwith Dexterity types using familiar APIs and techniques.Small over bigMega-frameworks be damned. Dexterity consists of a number of specialisedpackages, each of which is independently tested and reusable. Furthermore,packages should has as few dependencies as possible, and should declare theirdependencies explicitly. This helps keep the design clean and the codemanageable.Natural interaction over excessive generalityThe Dexterity design was driven by several use cases that express the way inwhich we want people to work with Dexterity. The end goal is to make it easyto get started, but also easy to progress from an initial prototype to acomplex set of types and associated behaviours through step-wise learning andnatural interaction patterns. Dexterity aims to consider its users - be theybusiness analysts, light integrators or Python developers, and be they new orexperienced - and cater to them explicitly with obvious, well-documented,natural interaction patterns.Real code over generated codeGenerated code is difficult to understand and difficult to debug when itdoesn't work as expected. There is rarely, if ever, any reason to scribblemethods or 'exec' strings of Python code.Zope 3 over Zope 2Although Dexterity does not pretend to work with non-CMF systems, as manycomponents as possible should work with plain Zope 3, and even where there aredependencies on Zope 2, CMF or Plone, they should - as far as is practical -follow Zope 3 techniques and best practices. Many operations (e.g. managingobjects in a folder, creating new objects or manipulating objects through adefined schema) are better designed in Zope 3 than they were in Zope 2.Zope concepts over new paradigmsWe want Dexterity to be "Zope-ish". Zope is a mature, well-designed (well,mostly) and battle tested platform. We do not want to invent brand newparadigms and techniques if we can help it.Automated testing over wishful thinking"Everything" should be covered by automated tests. Dexterity necessarily has alot of moving parts. Untested moving parts tend to come loose and fall onpeople's heads. Nobody likes that.