50 likes | 153 Views
Mixin / Aspect. John Newton Alfresco Wednesday, January 28, 2009. Background. Mixins or Aspects are metadata “plug-ins” Derived from Aspect Oriented Programming Cross-cutting concerns Core to JCR Exposes optional capabilities Used for Versioning and Locking
E N D
Mixin / Aspect John Newton Alfresco Wednesday, January 28, 2009
Background • Mixins or Aspects are metadata “plug-ins” • Derived from Aspect Oriented Programming • Cross-cutting concerns • Core to JCR • Exposes optional capabilities • Used for Versioning and Locking • Implements Records Mgmt for some vendors • Records aspects added when documents become records • Defines disposition information
Use Cases • Optional Functionality • Example: Expose Versioning as Mixins • Systems that don’t have mixins synthesize them thru API • Avoiding Multiple Inheritence • Example: Type system exposes business data – e.g. policies • Records have metadata • Avoid type explosion thru mixins • Adding behavior • Example: control lifecycle by updating data in mixin • Very REST-like – data, not procedures
Requirements • Get / Set properties that are not defined by a primary type, but are defined by an attached mixin / aspect. • Query properties that are defined in a mixin and return a target list that includes both primary type and mixin / aspect properties • Mechanism to set and remove aspects • A way to expose mixin / aspect from data dictionary
Approach / Discussion • Definition • Core to model (a la JCR) • Or a special type • Get / Set properties in Mixin / Aspect • Underlying object should know whether property is available. Does not need to be modeled in core type. • Query • Mixin / Aspect is JOINed to core type • Must be explicitly listed in FROM • Add / Remove Mixin / Aspect • Same type of mechanism as Policies • Ignored by systems that do not support Aspects