Elements_Content_Model_Overview.pdf
0 likes150 views
- Content models define the types of nodes, properties, and relationships that can exist in an Alfresco repository. They constrain nodes to a given type with a set of properties. - Aspects allow for cross-cutting properties and associations across multiple types, similar to multiple inheritance. Relationships between types are modeled with associations. - Content models are defined using XML files according to the content metamodel and deployed into the repository. Built-in models provide core functionality for folders, documents, and metadata.
Elements_Content_Model_Overview.pdf
- 1. Alfresco Elements Content Model Overview
- 2. 2 Alfresco Elements Contents Document information.............................................................................................................. 3 Content Model Overview.......................................................................................................... 4
- 3. Document information Content Model Overview 3 Document information Information in this document is subject to change without notice. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Alfresco. The trademarks, service marks, logos, or other intellectual property rights or Alfresco and others used in this documentation("Trademarks") are the property of Alfresco and their respective owners. The furnishing of this document does not give you license to these patents, trademarks, copyrights or other intellectual property except as expressly provided in any written agreement with Alfresco. The United States export control laws and regulations, including the Export Administration Regulations of the U.S. Department of Commerce, and other applicable laws and regulations apply to this documentation which prohibit the export or re-export of content, products, services, and technology to certain countries and persons. You agree to comply with all export laws, regulations and restrictions of the United States and any foreign agency or authority and assume sole responsibility for any such unauthorized exportation. You may not use this documentation if you are a competitor of Alfresco, except with Alfresco's prior written consent. In addition, you may not use the documentation for purposes of evaluating its functionality or for any competitive purposes. If you need technical support for this product, contact Customer Support by email at support@alfresco.com. If you have comments or suggestions about this documentation, contact us at training@alfresco.com.
- 4. Content Model Overview 4 Alfresco Elements Content Model Overview In this Alfresco Element content models are explored. You will understand what a content model is, understand the different ways content models can be implemented and how they are deployed through the bootstrapping process. You will also examine how content models are presented in the user interface. Everything which Alfresco stores, is stored as a node. This is a simple, uncomplicated model for recording entities, metadata, and relationships. The repository is a tree of nodes where each node supports one or more properties whose values may be of any data type and either single or multi-valued. A node has at least one parent, except for the root node, and may contain one or more child nodes. Nodes may also be related through arbitrary peer relationships. Any new node is assigned a Universally Unique Identifier, or UUID, which remains with it unchanged for the duration of its life. Any node can be referenced using a combination of store protocol, store name and UUID, this unique combination is known as the NodeRef. Nodes constrained • A node must be of a given kind. • A node must carry a defined set of properties.
- 5. Content Model Overview Content Model Overview 5 • A property must be of a given data type. • A value must be within a defined set of values. • A node must be related to other nodes in a particular way. These constraints allow the definition of entities within the content management domain. For example, many ECM applications are built around the notion of folders and documents. It is content modeling that adds this meaning to the node data structure. The possible types of nodes, properties, associations and aspects, which a node supports are all defined by the content model. In the example we can see that folders can appear within folders and folders may contain documents, which in turn may have renditions. In this case the associations between folders and documents, would have been created by the user as they create objects, or nodes, in the system using a user interface. Whereas the rendition relationship, would have been created automatically by the system, based on a user request or rule in the system. Out of the box, Alfresco comes prepackaged with several content models for support of the common or standardized aspects of ECM, especially for Document and Records Management. You can accomplish a lot with just these models but, if you want to break beyond the classic file system, you’ll need to roll up your sleeves and get modeling to support the specific needs of your ECM requirement. Content modeling is really all about metadata, that is, data describing data. Three layer metadata model To put content modeling in context, Alfresco talks in terms of the following three layer metadata model. The first layer, M0, represents the nodes, properties, and relationships held in the Alfresco content repository. These entities are managed through the various content repository services, such as the file folder service or CMIS (Content Management Interoperability Services). The next layer, M1, is a content model that defines a set of related definitions to constrain the nodes in layer M0. Many content models may be registered with the content repository. A content model is itself described by the next layer, M2, the content metamodel. This is the section which we focus on, as this is how content models are expressed for extending Alfresco. If you do not understand the content metamodel, you cannot define a content model. There are already some standardized content metamodels: the CMIS data model and JSR-170 node type model. In summary, we will be learning about the Alfresco content metamodel (M2), in order to define one or more content models (M1), to constrain the structure of your nodes (M0) held in your content repository. Type, properties and constraints At the heart of the content metamodel is a type. If you are familiar with object-oriented models then a type is just like a type or class and should be familiar. It represents objects in the real world with support for properties and the ability to inherit the definition of a parent type. Properties are named items of metadata associated with the type where each property is of a given data type. Constraints can be applied to restrict the values of a property.
- 6. Content Model Overview 6 Alfresco Elements Aspects Alfresco supports aspects in its data model, these are extremely useful and flexible modeling tools. An aspect supports the same capabilities as a type, meaning it supports properties, and may be related to and may inherit the definition of a parent aspect. On the surface, aspects seem very similar to types, but there is one important distinguishing feature, which is that aspects may be shared across types. In other words, aspects allow cross-cutting of the content model, which is the sharing of property and association definitions by attaching them to multiple types. This is the content metamodel equivalent of multiple inheritance. Associations Relationships between types are modeled with associations, of which there are two kinds: child associations and peer associations. Child associations provide the ability to model compositions where the parent effectively owns the children and, as such, operations like delete will propagate through to the children, avoiding orphans. Peer associations, on the other hand, define a relationship between two objects where neither object is superior to the other. Associations can be created between two different types, a type and aspect, or between a type and itself.
- 7. Content Model Overview Content Model Overview 7 Content models When a node is initially created in the system it must be of a given type from any of the content models. By default when a user creates a document the type will be a cm:content type. The type defines the properties which the node will have, a node may then have one or more aspects applied to it. These aspects may come with many properties of their own (or none at all), in this way a sophisticated range of metadata can be applied to a node. Built-in models In order to support the functionality which Alfresco provides as an ECM system some content models need to exist in the repository. Alfresco uses exactly the same techniques to define
- 8. Content Model Overview 8 Alfresco Elements content models as we describe on this course. The built-in content models are useful because they contain repository functionality and behavior and the Alfresco clients know how to deal with them, for example the display of a date datatype in Share. These built-in models can be used by you as a developer to extend the system, in some cases you need to use the content models, unless you want to do a lot of work re-writing functionality! Although you should have little need to inspect the models directly you will find each model in a separate file called <name>Model.xml (e.g. dictionaryModel.xml) in the directory: • {tomcat_root}/webapps/alfresco/WEB-INF/classes/alfresco/model The primary built-in models are shown in the table below: Abbreviation Name File Description app application application application specific types and aspects, in this case folders, links and simple workflow. cm content model contentModel.xml A complex model which contains the major types of the system such as content, person, etc. based off the system model. d dictionary dictionaryModel.xml The data types used in other models. sys system systemModel.xml Contains the base types used in other models. usr user in alfresco.war Contains the definition of authorities. Note this file in embedded in the .war file and is not found in the models directory. The following lists the built-in types and aspects which are available as a result of the built-in models. This is a reference list and may change over times as new types and aspects are added. Model deployment
- 9. Content Model Overview Content Model Overview 9 Content models are simply XML files which correspond to a particular schema. A content model can be deployed in a number of ways into an Alfresco repository and once deployed the content model objects are then available for use. However simply deploying a content model into the content server has no effect at all on the Alfresco clients. Additionally to make sure that your model can be used successfully in client applications you will also need to configure the Alfresco clients, such as Share, to be model- aware. This concludes the overview of Alfresco content models.