Understanding the Asset Types and Asset Models

What Are Asset Types?

Content contributors and marketers can create assets such as articles, images, videos when you make asset types for those assets available to them. When creating your asset model, you may want to leverage the asset types available in the avisports sample site.

An asset type defines the characteristics of asset objects of that type. An asset is an object that is stored in the WebCenter Sites database and can be created, edited, inspected, deleted, duplicated, placed into workflow, tracked through revision tracking, searched for, and published to your delivery (live) site.

This figure shows the WebCenter Sites Content-Entry form and the relationship of field names and field values to the database table for an asset type.

Figure 4-1 Asset Types: Database Tables and WebCenter Sites Forms

Description of "Figure 4-1 Asset Types: Database Tables and WebCenter Sites Forms"

Developers design and create asset types while designing your content management system and your online sites. Content providers then create and edit assets of those types.

In general, assets perform one of the following three roles:

Provide content that visitors read and examine on your online sites
Provide the formatting logic or code for displaying the content
Provide data structure for storing the content in the WebCenter Sites database

The developer's job is to design asset types that are easy for content providers to work with on the management system and that can be delivered efficiently to visitors from the delivery system.

Several core asset types are delivered by WebCenter Sites and Oracle WebCenter Sites: Engage. Because WebCenter Sites has a stack architecture, the core asset types are made available as follows:

WebCenter Sites delivers the template, query, collection, SiteEntry, CSElement, Link, and page asset types. All of the other modules and products use the template and page asset types.
WebCenter Sites delivers the attribute editor asset type. It supports any flex attribute asset types that you create.
Engage delivers the visitor attribute, history attribute, history definition, segment, recommendation, and promotion asset types.

Assets of these types provide format or logic for the display of asset types that hold your content by retrieving, ordering, organizing, and formatting those assets. In other words, you use the core asset types to organize and format the content on your online site.

Asset Types Delivered with WebCenter Sites

Asset types delivered with WebCenter Sites provide basic site design logic. You can create as many individual assets of these types as you need, but you cannot modify the asset types themselves:

Query: Stores queries that retrieve a list of assets based on selected parameters or criteria. You use query assets in page assets, collections, and recommendations. The database query can be either written directly in the New or Edit form for the query asset as a SQL query, or written in an element (with WebCenter Sites query tags or a as a search engine query) that is identified in the New or Edit form.
Collection: Stores an ordered list of assets of one type. You build collections by running one or more queries, selecting items from their resultsets, and then ranking (ordering) the items that you selected. This ranked, ordered list is the collection. For example, you could rank a collection of articles about politics so that the article about last night's election results is number one.
Page: Stores references to other assets. Arranging and designing page assets is how you represent the organization or design of your site. You design page assets by selecting the appropriate collections, articles, imagefiles, queries, and so on for them. Then, you position your page assets on the Site Navigation node that represents your site in the tree on the left side of the WebCenter Sites Admin interface.

Note that a page asset and a WebCenter Sites page are quite different. The page asset is an organizational construct that you use in the Site Navigation node as a site design aid and to identify data in your elements. A WebCenter Sites page is a rendered page that is displayed in a browser or by some other mechanism.
Template: Stores code (XML or JSP and Java) that renders other assets into WebCenter Sites pages and pagelets. Developers code a standard set of templates for each asset type (other than CSElement and SiteEntry) so that all assets of the same type are formatted in the same way.

Content providers can select templates for previewing their content assets without having access to the code itself or being required to code.
CSElement: Stores code (XML or JSP and Java) that does not render assets. Typically, you use CSElements for common code that you want to call from multiple templates (a banner perhaps). You also use CSElements to provide the queries that are needed to create DynamicList recommendations in Engage.
SiteEntry: Represents a WebCenter Sites page or pagelet and has a CSElement assigned as the root element that generates the page. Template assets do not have associated SiteEntry assets because they represent both an element and a WebCenter Sites page.
Link: Stores a URL to an external website. You use this asset to embed an external link within another asset.
Attribute Editor: Is an attribute editor that specifies how data is entered for a flex attribute when that attribute is displayed on a New or Edit form for a flex asset or a flex parent asset. It is similar to a Template asset. However, unlike a Template asset, you use it to identify the code that you want WebCenter Sites to use when it displays an attribute in its interface, not when it displays the value of an attribute on your online site.

Because the data needs of each organization using a WebCenter Sites content management system are different, there are no default asset types that represent content. However, the sample sites deliver sample content asset types that you can examine and modify for use on your sites.

Asset Types Delivered with Engage

The Engage application delivers several core asset types that you use to gather visitor information so that you can personalize the product placements and promotional offerings that are displayed for each visitor:

Visitor Attribute: Holds types of information that specify one characteristic only (scalar values). For example, you can create visitor attributes named years of experience, job title, or number of children.
History Attributes: Are individual information types that you group together to create a vector of information that Engage treats as a single record. This vector of data is the history definition. For example, a history type called purchases can consist of the history attributes SKU, itemname, quantity, and price.
Segments: Are assets that divide visitors into groups based on common characteristics (visitor attributes and history types). You build segments by determining which visitor data assets to base them on and then setting qualifying values for those criteria. For example, a segment could define people who live in Alaska and own fly fishing gear, or it could define people who bought a personal computer in the past six months, and so on.

After you define and categorize the visitor data that you want to collect, you use the following asset types to select, organize, and display the flex assets that represent your content on your online site:

Recommendation: Is like an advanced collection. It collects, assesses, and sorts flex assets (products or articles, perhaps) and then recommends the most appropriate ones for the current visitor, based on the segments that visitor belongs to.
Promotion: Is a merchandising asset that offers some type of value or discount to your site visitors based on the flex assets (products, perhaps) that the visitor is buying and the segments that the visitor qualifies for.

Note:

Engage interacts with assets that are built using the flex asset model only. You cannot program recommendations and promotions to work with assets that use the basic asset model.

What Are Asset Models?

Asset models (or data models) consist of asset types that content contributors and marketers use to create content assets. You can design two types of models, basic and flex. The asset types in the basic model are unalterable and suitable for predictable scenarios. The asset types in the flex model are hierarchal and changeable.

Basic: Asset types have a simple data structure. They have one primary storage table and simple parent-child relationships with each other.

Basic asset types are separate, standalone asset types that represent individual kinds of content: an article, an image file, a page, a query, and so on. You use the AssetMaker utility (located in the General Admin tree under the Admin node) to create basic asset types.
Flex: Asset types have a complex data structure with several database tables and the ability to support many more fields than do basic asset types. Additionally, they can have multiple parents, any number of grandparents, and so on, that they can inherit attribute values from.

Flex asset types comprise families of asset types that define each other and assign attribute values to each other. You use the Flex Family Maker utility (located in the General Admin tree under the Admin node) to create a family of flex asset types.

During the process of designing your online site with the WebCenter Sites content management system, you and others on your team create the asset types that should represent the content for your site. The WebCenter Sites template and page asset types provide the formatting framework for the asset types that represent your data, whether you use the basic data model or the flex data model.

The asset data model (basic or flex) that you should choose to represent the data that you want to display on your online site depends on the nature of that data, as described in the following two sections:

When to Use the Basic Model

The basic model is a good choice when your data has the following characteristics:

It is fixed, predictable: there will be no need to add attributes to the asset type.
It is homogenous: all assets of the same type have similar attributes.
It has a moderate number of attributes. You are limited by your database as to how many columns/attributes you can have in the asset type table for a basic asset.
You want to use the static publishing method. There are very limited applications of the flex asset model in which it makes sense to use the static publishing method.
Visitors browse your online site by navigating from link to link.

When the data for an asset type can be imagined as a spreadsheet, as a simple flat table where each asset of that type is a single record and every record has the same columns, that asset type should use the basic asset model.

When to Use the Flex Model

The flex model is the right choice when your data has the following characteristics:

It has lots of attributes. For example, products can have potentially hundreds of attributes. Because attribute values for the flex family member are stored as rows rather than columns, and flex assets can physically have many more attributes than basic assets can.
It can be represented in a hierarchy in which assets inherit attribute values from parent assets.
You cannot predict what attributes might be necessary in the future and your data might need additional attributes periodically.
Asset instances of the same type can vary widely. That is, not all assets of that type should have the same attributes. For example, a bath towel product asset would have attributes that a toaster product asset would not, but both the bath towel and the toaster are product assets.
Visitors browse your online site by navigating through drill-down searches that are based on the attribute values of your data.
You want to use Engage.

Products fit into the flex asset model because markets are constantly changing. You cannot always predict what products you will be selling next year or what attributes those products will have.

Flex data model is the right fit when you business needs require you to make modifications to your asset types such as adding or changing their attributes. The flex asset model gives you the extensibility that you have to represent data whose characteristics cannot be predicted.

The Basic Asset Model

WebCenter Sites includes the basic asset model by default. This data model uses one database table per asset type. All basic assets of the same type have the exact same fields (properties), and all assets of a single type are stored in the same database table. Most of the core WebCenter Sites asset types use this model.

The AssetMaker utility lets you create basic asset types. You code XML files called asset descriptor files using a custom tag named PROPERTY and then upload the file with AssetMaker. A property is both a column and a field. A PROPERTY statement defines a column in the table that stores assets of that type and defines how data is to be entered into the corresponding field for that column in the WebCenter Sites forms.

For information about coding asset descriptor files and creating new basic asset types, see Designing Basic Asset Types.

Familiarize yourself with the following:

Relationships Between Basic Assets

Basic asset types have very simple parent-child relationships. You use these relationships to associate or link assets to each other. When you design the online pages for your online sites you code template elements that identify, extract, and then display an asset's children or parent assets in appropriate ways.

The relationships that basic assets can have with each other are called associations and unnamed relationships. When these relationships occur between individual assets, they are written to the AssetRelationTree table.

Associations

Associations are defined, asset-type-specific relationships that are represented as fields in the WebCenter Sites asset forms. After you create an asset type with AssetMaker, you use the Association form for that asset type to create association fields.

You use associations to set up relationships that make sense for the asset types in your system and then you use the names of these relationships to identify the related assets and display them in appropriate ways on your site pages. For example, in a site where an asset named article had three associations with an imagefile asset type, such as Main ImageFile, Teaser ImageFile, and Spot ImageFile, the article templates would be coded to display the imagefiles that are linked to articles through these associations. The association is what enables the template to determine which imagefile is the correct one to display for an individual article asset. When a content provider selects an image asset in the imagefile field of the New and Edit article forms, the selected imagefile asset becomes a child of the article asset. (Note that this same imagefile asset can also be a child of other articles.)

When you create a new association between asset types, WebCenter Sites creates a row for that type of association in the Association table. Then, when you create an asset and specify the name of another asset in an association field, that relationship is written to the AssetRelationTree table.

Unnamed Relationships

Unnamed relationships occur when you build a collection, the items in the collection become children of the collection.

Category, Source, and Subtype

There are three additional ways to organize or categorize basic assets: category, source, and subtype. Categories and subtypes are specific to an asset type. Source, however, applies to all the asset types in a content management site. In other words, source is site-specific.

Source

Source is a column and field that you can use to identify where an asset originated. Although WebCenter Sites provides administrative support (through the Source form) for you to use this feature in the design of your online site, the source column does not exist by default in the primary storage tables for basic asset types other than Article. To use source with your basic asset types, you must include a property statement in your asset descriptor file for it.

For example, a banking site might have sources named WireFeed, Asia Pulse, UPI, and so on. Certain online pages select stories to display based on the results of queries that search for articles based on the value in their source column.

After you create a new basic asset type, you add new sources in the Source form in the Admin node on the General Admin tree, if necessary. New sources are written to the Source table, which serves as the lookup table for the Source field on the New and Edit asset forms for basic-style assets.

Subtype

The subtype concept provides a way to further classify an asset type. In the flex asset data model, the definition asset types create subtypes of flex assets and flex parent assets. In the basic asset data model, the concept of subtype is implemented through the subtype column in the primary storage table for the asset type.

The WebCenter Sites application uses the value of an asset's Subtype in many ways:

For Template assets, subtype means the type of asset that the template formats. Templates that format articles are a different subtype of template than templates that format images. When you create an article asset, only the templates that format articles appear as options in the Template field on that asset's New or Edit form.

In addition, you can use the Oracle WebCenter Sites: Contributor interface to specify a subtype that is displayed using a given template. For example, if your website uses two subtypes of article asset, Sports and News, you can create a template that only displays articles with the Sports subtype.
For query assets, subtype means the type of asset that the query returns. Query assets that return articles are a different subtype of query asset than those that return imagefiles.
For collection assets, subtype means the type of asset that the collection holds. Collections that hold articles are a different subtype of collection asset than those that hold imagefiles.
For the basic asset types that you design, subtype is designed to classify an asset based on how it is rendered. You can define a default template for each subtype of an asset type for each of your publishing targets.

You are required to create subtypes only when a different template should be assigned to assets of a specific type based on the publishing target for the asset.

The field named Subtype is displayed in those assets' New and Edit forms for whose asset types you create any subtypes. The drop-down list in the field displays all the possible subtypes for that asset type.

Note:

In the flex asset model, the definition asset types serve as subtypes. For example, the flex family in the avisports sample site has a definition named Article. This means that there is one subtype for article assets: the Article subtype.

For some asset types, the subtype is set implicitly and cannot be changed. Other asset types allow users to choose a subtype for the asset using the Contributor interface. Table 4-1 lists the WebCenter Sites asset types according to whether they have configurable subtypes.

Table 4-1 Implicit Subtypes vs. Configurable Subtypes

Implicit Subtypes	Configurable Subtypes
All flex assets Query assets Collection assets Template assets Page assets	All custom basic assets (made with AssetMaker) Article assets Image assets Linkset assets Recommendation assets Link assets

For information about setting configurable subtypes, see Designing Basic Asset Types.

Basic Asset Types and the Database

Although there is one primary storage table for basic asset types, WebCenter Sites keeps other kinds of supporting information for basic assets in other tables. When you create a new asset of a basic type, WebCenter Sites writes to the following database tables:

The primary database table that holds assets of its type. For example, each page asset has a row in the Page table and each article asset has a row in the Article table.

These tables store all of the asset's attribute or field values, such as the asset's name, its object ID, who created it, which template it uses, and so on. The name of this table always matches the name of the asset type.

When you create a new basic asset type, the AssetMaker utility creates the primary storage table (a WebCenter Sites object table) for the asset type as a part of that process.
The AssetRelationTree table, if the asset has associations with other assets. The relationships that basic assets can have are described in Relationships Between Basic Assets.
The AssetPublication table, which specifies which content management sites (publications) give you access to the asset. If the asset is shared among sites (publications), there is a row entry for each pubid. A pubid is a unique value that identifies a site (publication).
The SitePlanTree table, if the asset is a page asset. This table stores information about the page asset's hierarchical position in your site navigation.

When you develop the templates that display the assets that represent your content, you code elements with XML or JSP tags that extract and display the information from the tables in the preceding list.

Be sure to examine the New and Edit forms for the various sample asset types and to use the Explorer tool to examine the tables in your WebCenter Sites database.

Note:

Do not use the Explorer tool to modify the data in any of these tables. All editing of assets and their related tables should be done only through the WebCenter Sites interface.

Template Asset Type and the Database

Although the Template asset type is a core asset type, it does not use the basic asset model. It is a complex asset type with entries in the following database tables:

The Template table (primary storage table)
The SiteCatalog table
The ElementCatalog tables

When you create a new Template asset, WebCenter Sites automatically creates entries in both the SiteCatalog and ElementCatalog tables for it.

Default Columns in the Basic Asset Type Database Table

WebCenter Sites needs several default columns for its basic functionality. So, AssetMaker creates each of the columns described in the following table in the asset type's primary storage table in addition to the columns defined in the asset descriptor file for that asset type.

Note that you do not have to code your asset descriptor files to include property statements for the columns in this table:

Table 4-2 Columns in an Asset Type's Primary Storage Table

Default Column (Field) Name Description Where It's Displayed in the WebCenter Sites Interface

Default Column (Field) Name	Description	Where It's Displayed in the WebCenter Sites Interface
`id`	A unique ID for each asset, automatically generated by WebCenter Sites when you create the asset. You cannot change the value in this field.	Forms: Inspect Edit Status search forms
`name`	A unique name for the asset. Names are limited to 64 alphanumeric characters.	Forms: New Edit Inspect, Status Also in the search results lists.
`description`	A short description of the asset that offers more information than just the name.	Forms: New Edit Inspect Status Also in the search results lists.
`status`	The status of the asset, one of the following status codes obtained from the `StatusCode` table: PL: created ED: edited RF: received (from XMLPost, for example) UP: upgraded from Xcelerate 2.x VO: deleted (void) WebCenter Sites controls the value in this field. This field cannot be edited manually.	Forms: Status, if the status of an asset is either PL (created) or ED (edited) Note that assets with a status of VO (deleted) are not displayed anywhere in the WebCenter Sites Windows interface.
`createdby`	The identity of the user who originally created the asset. This user name is obtained from the `SystemUsers` table. WebCenter Sites controls the value in this field. It cannot be edited manually.	Forms: Status Also, the Revision History list if revision tracking is enabled for assets of this type.
`createddate`	The date and time that the asset was written to the database for the first time. WebCenter Sites controls the value in this field. It cannot be edited manually.	Forms: Status Also, the Revision History list if revision tracking is enabled for assets of this type.
`updatedby`	The identity of the user who most recently modified the asset in any way. This user name is obtained from the `SystemUsers` table. WebCenter Sites controls the value in this field. It cannot be edited manually.	Forms: Status Also, the Revision History list if revision tracking is enabled for assets of this type.
`updateddate`	The date on which the information in the status field was changed to its current state. WebCenter Sites controls the value in this field. It cannot be edited manually.	Forms: Status Also, the Revision History list if revision tracking is enabled for assets of this type.
`startdate`	Promotion assets (an Engage asset) have durations during which they can be displayed on the visitor pages on your live system. This column stores the start time of the promotion's duration. The promotion asset type is the only default asset type that uses this column. For information on using startdate and enddate fields for your asset types, see Example 5-7 in Creating Basic Asset Types.	Forms: Duration, Edit, and Inspect for promotion assets. New, Edit, Inspect, and Status if you enable it for other asset types.
`enddate`	For promotion assets (an Engage asset), this column stores the end time of the promotion's duration. The promotion asset type is the only default asset type that uses this column.	Forms: Duration, Edit, and Inspect for promotion assets. New, Edit, Inspect, and Status if you enable it for other asset types.
`subtype`	The value of the asset's subtype. The subtype is set in different ways for different assets. See Subtype.	Forms: New, and Edit for Template assets (Asset Type field). New, and Edit for query assets (Result of Query field). New, and Edit for any asset type that has subtypes configured for it. Set Default Templates.
`filename`	The name to use for the file created for this asset during the Export to Disk publishing method. The page and article asset types are the only asset types that have this field enabled by default. For information on using the `filename` field for your asset types, see Example 5-7 in Creating Basic Asset Types.	Forms: New and Edit for page and article assets, by default. New and Edit for any other asset type that has the field enabled.
`path`	The directory path to use for exported page files that are generated from child assets of this asset when the Export to Disk publishing method renders that asset into a file. The page and article asset types are the only asset types that have this field enabled by default. For information on using the `filename` field for your asset types, see Example 5-7. in Creating Basic Asset Types. in Creating Basic Asset Types.	Forms: New and Edit for page and article assets, by default. New and Edit for any other asset type that has the field enabled.
`template`	The template for the asset. This is the template that is used to render the asset when it is either published with Export to Disk or rendered on a live dynamic delivery system. This template is also used to calculate the dependencies when the asset is approved for the Export to Disk publishing method, unless the asset type has subtypes and there is a default approval template assigned for the asset based on its subtype.	Forms: New Edit Inspect Status
`category`	The category code of the category assigned to the asset, if any. If you decide to use the `category` field to organize assets, you add category codes in the Asset Types forms in the Admin node on the General Admin tree.	Forms: New Edit Inspect Status
`urlexternaldoc` Deprecated	If the asset was entered with the Sites Desktop interface rather than the WebCenter Sites interface, stores the external document that is the source for the asset. WebCenter Sites controls the value in this field. It cannot be edited manually.	Not applicable
`externaldoctype` Deprecated	The mimetype of the file held in the `urlexternaldoc` field. WebCenter Sites controls the value in this field. It cannot be edited manually.	Not applicable
`urlexternaldocxml`	Reserved for future use.	Not applicable

id

A unique ID for each asset, automatically generated by WebCenter Sites when you create the asset.

You cannot change the value in this field.

Forms:

Inspect
Edit
Status
search forms

name

A unique name for the asset. Names are limited to 64 alphanumeric characters.

Forms:

New
Edit
Inspect,
Status

Also in the search results lists.

description

A short description of the asset that offers more information than just the name.

Forms:

New
Edit
Inspect
Status

Also in the search results lists.

status

The status of the asset, one of the following status codes obtained from the StatusCode table:

PL: created

ED: edited

RF: received (from XMLPost, for example)

UP: upgraded from Xcelerate 2.x

VO: deleted (void)

WebCenter Sites controls the value in this field. This field cannot be edited manually.

Forms: Status, if the status of an asset is either PL (created) or ED (edited)

Note that assets with a status of VO (deleted) are not displayed anywhere in the WebCenter Sites Windows interface.

createdby

The identity of the user who originally created the asset. This user name is obtained from the SystemUsers table.

WebCenter Sites controls the value in this field. It cannot be edited manually.

Forms: Status

Also, the Revision History list if revision tracking is enabled for assets of this type.

createddate

The date and time that the asset was written to the database for the first time.

WebCenter Sites controls the value in this field. It cannot be edited manually.

Forms: Status

Also, the Revision History list if revision tracking is enabled for assets of this type.

updatedby

The identity of the user who most recently modified the asset in any way. This user name is obtained from the SystemUsers table.

WebCenter Sites controls the value in this field. It cannot be edited manually.

Forms: Status

Also, the Revision History list if revision tracking is enabled for assets of this type.

updateddate

The date on which the information in the status field was changed to its current state.

WebCenter Sites controls the value in this field. It cannot be edited manually.

Forms: Status

Also, the Revision History list if revision tracking is enabled for assets of this type.

startdate

Promotion assets (an Engage asset) have durations during which they can be displayed on the visitor pages on your live system. This column stores the start time of the promotion's duration.

The promotion asset type is the only default asset type that uses this column.

For information on using startdate and enddate fields for your asset types, see Example 5-7 in Creating Basic Asset Types.

Forms:

Duration, Edit, and Inspect for promotion assets.
New, Edit, Inspect, and Status if you enable it for other asset types.

enddate

For promotion assets (an Engage asset), this column stores the end time of the promotion's duration.

The promotion asset type is the only default asset type that uses this column.

Forms:

Duration, Edit, and Inspect for promotion assets.
New, Edit, Inspect, and Status if you enable it for other asset types.

subtype

The value of the asset's subtype. The subtype is set in different ways for different assets. See Subtype.

Forms:

New, and Edit for Template assets (Asset Type field).
New, and Edit for query assets (Result of Query field).
New, and Edit for any asset type that has subtypes configured for it.
Set Default Templates.

filename

The name to use for the file created for this asset during the Export to Disk publishing method.

The page and article asset types are the only asset types that have this field enabled by default.

For information on using the filename field for your asset types, see Example 5-7 in Creating Basic Asset Types.

Forms:

New and Edit for page and article assets, by default.
New and Edit for any other asset type that has the field enabled.

path

The directory path to use for exported page files that are generated from child assets of this asset when the Export to Disk publishing method renders that asset into a file.

The page and article asset types are the only asset types that have this field enabled by default.

For information on using the filename field for your asset types, see Example 5-7. in Creating Basic Asset Types. in Creating Basic Asset Types.

Forms:

New and Edit for page and article assets, by default.
New and Edit for any other asset type that has the field enabled.

template

The template for the asset.

This is the template that is used to render the asset when it is either published with Export to Disk or rendered on a live dynamic delivery system.

This template is also used to calculate the dependencies when the asset is approved for the Export to Disk publishing method, unless the asset type has subtypes and there is a default approval template assigned for the asset based on its subtype.

Forms:

New
Edit
Inspect
Status

category

The category code of the category assigned to the asset, if any.

If you decide to use the category field to organize assets, you add category codes in the Asset Types forms in the Admin node on the General Admin tree.

Forms:

New
Edit
Inspect
Status

urlexternaldoc

Deprecated

If the asset was entered with the Sites Desktop interface rather than the WebCenter Sites interface, stores the external document that is the source for the asset.

WebCenter Sites controls the value in this field. It cannot be edited manually.

Not applicable

externaldoctype

Deprecated

The mimetype of the file held in the urlexternaldoc field.

WebCenter Sites controls the value in this field. It cannot be edited manually.

Not applicable

urlexternaldocxml

Reserved for future use.

Not applicable

The Flex Asset Model

In the flex asset model asset types inherit attributes. You can modify this model to meet unpredictable content needs. For example, a car company keeps adding new models. And, all models share some features. Content for such a car site needs the flex asset model.

The main characteristics of the flex asset model are:

Flex assets are defined by flex definitions. A flex definition is an asset type that determines which flex attributes make up an individual flex asset. Flex definitions create subtypes of the flex asset type.
The definition asset types create subtypes of flex and flex parent assets, which allows individual instances of a flex asset or flex parent asset type to vary widely.
Flex attributes are assets. The flex data model lets you add flex attributes to (or remove them from) existing flex asset types at any time.
Flex filters can take the data from one flex attribute, transform or assess it in some way, and then store the results in another flex attribute when you save the flex asset. The resulting value from a flex filter action is called a derived attribute value. See Creating Flex Filters.
Flex assets can inherit attribute values, even derived values, from their flex parents, which means that you can represent your data in hierarchies.

You do not create individual flex asset types as you do basic asset types; instead, you create a flex family of asset types.

See these topics:

The Flex Family

The flex asset data model can be thought of in terms of a family of asset types. There are six asset types in a flex family. Five are required, the sixth is optional, as indicated in Table 4-3.

Table 4-3 Flex Family Members

Flex Family Member	Number Per Family
flex attribute asset type	one
flex parent definition asset type	one or more
flex definition asset type	one or more
flex parent asset type	one or more
flex asset type	one or more
flex filter asset type	none or more

Whereas some asset types are used exclusively by developers to create the other asset types in the data model, the flex asset type is always used by the content providers to create assets of that type. (When necessary, authorized users can be given access to additional flex family members.)

To create a flex family, you access the Add New Flex Family form by double-clicking Add New Family, located in the General Admin tree on the Admin node under Flex Family Maker. under the Flex Family Maker node in the Admin interface. In the form, you name each of the asset types in the family. For example, a site has a flex family named product family. The flex asset is called the product asset, the flex attribute is called the product attribute, and so on.

The key member of a flex family is the flex asset. The flex asset is the unit of data that you extract from the database and display to the visitors of your online site (delivery system). All of the other members in the family contribute to the flex asset member in some way.

While the flex asset is the key, the attributes are the foundation of the flex asset model. An attribute is an individual component of information. For example, color, height, author, headline. You use attributes to define the flex assets and the flex parents. Flex assets inherit attribute values from their parents who inherit attribute values from their parents and so on.

You decide which attributes describe which flex assets and which flex parents by creating templates with the flex definition and flex parent definition asset types. Flex parents and their definitions implement the inheritance of attribute values.

Note that a flex parent or a flex asset cannot be defined by attributes of two types. A site might have two or more kinds of attributes. For example: product attributes and content attributes. A product asset (the flex asset member in the product flex family) can be defined by product attributes only. Its definition cannot include content attributes.

A flex filter enables you to configure some kind of action to take place on the value of an attribute and then save the results of the action when the flex asset is saved. For example, you can configure a filter that converts the text in a Word file into HTML code.

In summary, the flex asset member of a flex family is the reason for the family, the unit of content that you want to display. The other members of a flex family provide data structure for the flex asset. However, because all of the members in the family are assets, you can take advantage of the standard WebCenter Sites features like revision tracking, workflow, search, and so on.

Parent, Child, and Flex Assets

When you are using the flex asset data model, the phrase parent-child relationship refers to the relationship between a flex asset and its flex parent asset(s). This is a different parent-child relationship than the ones that basic assets have through asset associations.

Although it is possible for flex assets to have the kinds of parent-child relationships that basic assets do, it is unlikely for the following reasons:

WebCenter Sites provides the ASSETSET and SEARCHSTATE tag families, which you use instead of the collection and query asset types to select the flex assets that you want to display. For more information about this tag family, see Assetsets and Searchstates.
Flex assets have no need for associations. For example, to assign an image file to a flex asset like a product, you can create an attribute that identifies the image file and assign it to the definition for the flex asset.

The Flex Family in the Avisports Sample Site

In the avisports sample site there is one flex family that you can examine. To better understand the following descriptions of the sample flex asset types, examine some article and image assets in the Contributor interface as you read this section.

The Avisports Flex Family

The flex family in the avisports sample site provides the data structure for the articles and images shown on the avisports sample site. It creates an online sports news website.

These are the asset types in the avisports flex family:

ContentAttribute: The flex attribute asset type used to define the attributes for the articles, images, and parents in the avisports sample site. For example, there are attributes named headline, subheadline, author, relatedImage, and so on.
ContentParentDef: The flex parent definition asset type in the avisports sample site's flex family. It is used to create subtypes of parents. There is one: Category.
ContentDef: The flex definition asset type in the avisports sample site's flex family. It is used to create a subtype for each definition: Article, ArticleImage, and Image. All of the AVIArticle assets in this site are defined by the Article definition. The AVIImage assets in this site are defined by either the Image or ArticleImage definition.
ImageCategory: A flex parent that represents categories of images such as Running images, Skiing images, Baseball images, and so on.
ArticleCategory: A flex parent that represents categories of articles such as Running Articles, Baseball Articles, Skiing Articles, and so on.
AVIImage: A flex asset type that stores an uploaded image file. Image assets represent the images that are shown on the avisports website.
AVIArticle: A flex asset type that stores the text of an article and information about it. It has attributes such as headline, byline, subheadline, body, and so on.

Notice that there are three content definitions in the avisports sample site's flex family, and only two content asset types. The Article definition is used by the AVIArticle asset type. The Image and ArticleImage definitions are both used by the AVIImage asset type.

Flex Attributes

Flex attributes are the foundation of the flex asset model. An attribute represents one unit of information. You use attribute assets to define flex assets and flex parents. They are then displayed as fields in the New and Edit forms for your flex assets and their parents.

An attribute is similar to a property for a basic asset. As does a property, an attribute defines the kind of data that can be stored in a column in a WebCenter Sites database table and describes a field in the forms. However, while a property defines one column in an asset type's database table, an attribute is an asset with database tables of its own.

This data structure (attributes as assets rather than columns) is a one of the main reasons why flex assets are so flexible.

Once again, a flex parent or a flex asset cannot be defined by attributes of two types. For example, in a site that has a product flex family and a content flex family, the product asset type can be defined by product attributes only. Its definition cannot include content attributes.

Note:

The data stored by flex attributes that you removed is not deleted from the database (queries continue to return this data).

Data Types for Attributes

The data types for your attributes are defined by the WebCenter Sites database properties located in the wcs_properties.json file, categorized under Core.

The following table lists the data types for flex attributes, the properties that define the data types, and the files where the properties are located.

Table 4-4 Data Types for Flex Attributes

Type	Property
`date`	`cc.datetime`
`float`	`cc.double`
`integer`	`cc.integer`
`money`	`cc.money`
`string`	`cc.varchar`
`text`	`cc.bigtext`
`asset`	`cc.bigint`
`blob`	`cc.bigint`

Default Input Styles for Attributes

When a flex attribute is displayed as a field on a New or Edit form, it has default input styles based on its data types. The following list presents the default input styles for flex attributes:

Date: input boxes that look like the following:

Figure 4-2 Date Attribute

Description of "Figure 4-2 Date Attribute"
Float: A text field with decimal position enforced.
Integer: A text field.
Money: A text field with currency format enforced.
String: A text field that accepts up to 255 characters.
Text: A text box. The number of characters that it accepts depends on the database and database driver you are using.
Asset: A drop-down list of all the assets of the type that was specified.
Blob: A text field with a Browse button.

Instead of using the default input style, you can create an attribute editor and assign it to the attribute. Attribute editors are assets but they are also similar to the INPUTFORM statement in an asset descriptor file for a basic asset -- they specify how data is entered into the attribute field. For more information about attribute editors, see Designing Attribute Editors.

Foreign Attributes

You can have flex attributes that are stored in foreign tables, that is, foreign attributes. They are subject to the following constraints:

The foreign table must be registered with WebCenter Sites. That is, the foreign table must be identified to WebCenter Sites in the SystemInfo table.
The foreign table must have a column that holds an identifier that uniquely identifies each row. The identifier must have fewer than 20 characters.
The foreign table must have a column that is reserved for the attribute data value, which can be of any appropriate data type. For example, for a string type attribute, the data type must be appropriate for a string.

Flex Parents and Flex Parent Definitions

Flex parents and their flex parent definitions are organizational constructs that do two things:

Implement the inheritance of attribute values. The parent definitions set up (describe) the rules of inheritance and the parents pass on attribute values to the flex assets according to those rules of inheritance.
Determine the position of a flex asset on the tabs that display your assets in the WebCenter Sites interface. The hierarchy of the parents and the flex assets on the tabs in that tree are based on the hierarchy set up with the parent definitions.

Each parent asset type has its own set of attributes, as specified in its parent definition. The parent definition creates a form that you see in the WebCenter Sites interface.

Note:

While creating a parent definition, if you add the parent definition as its own parent, publishing errors may occur.

You use parents to organize or manage the flex assets by passing on attribute values that are standard and do not have to vary for each individual child asset of that parent.

Parent asset types affect how you and the content providers see and interact with the data within the WebCenter Sites interface.

For example, say there is a site named ProductSite that has two parent definitions: Category and SubCategory. Their sole purpose is to create structure on the Content Tree (in the Contributor interface).

When the product parent's definition is Category, the product parent is displayed at the top level on the Content Tree. When the product parent's definition is SubCategory, the product parent is displayed at the second level and it has a parent of its own, as shown in the following:

Figure 4-3 Product Node in the Content Tree

Description of "Figure 4-3 Product Node in the Content Tree"

In Figure 4-3, there are several top-level product parents: Compact Fluorescent, Halogen, and so on. They were created with the Category definition. The next-level product parents, such as Double BIAX and 2-Pin, Double BIAX and 4-pin, and so on were created with the Subcategory definition.

Business Rules and Taxonomy

The purpose of parent definitions and parent assets is not only to express the taxonomy of your data. They also allow you to apply business rules (logic) without risk of input error from end users. If you created a flex asset of a specific definition and there are dependencies that it should inherit, that flex asset should have a parent.

For example, here is a simple product, a toaster with five attributes:

SKU = 1234
Description = toaster
Price = 20
CAT1 = Kitchen
CAT2 = Appliances

When the value of CAT2 is Appliances, the value of CAT1 can only be Kitchen. In other words, there is a business rule dependency between the value of CAT1 and the value of CAT2.

In this kind of case, there is no reason to require the content providers to fill in both fields. Because every field whose data has to be entered manually is a field that might hold bad data through input error, you would use inheritance to impose the business rule:

Make CAT1 and CAT2 parent definitions.
Make Kitchen a parent created with the CAT1 definition and Appliances a parent created with the CAT2 definition.
Make Kitchen the flex parent of Appliances.

Now, when content providers create products and select Appliances for CAT2, the value for CAT1 is determined automatically through inheritance.

Flex Assets and Flex Definition Assets

A flex asset is the reason for the flex family. It is the asset type that represents the end goal; a product, a piece of content that is displayed, and so on. For example, in the avisports sample site there are two flex asset types:

Article (flex), an asset that holds text.
Image (flex), an asset that holds an uploaded image file.

All of the other members in the family contribute to the flex asset member in some way.

A flex definition asset describes one kind of flex asset in a flex family; for example, a shoe, a toaster, a bowling ball, a brochure, a newsletter, an article, and so on. A flex definition asset is a template in that it directly affects a form that you see in the Contributor interface.

The avisports sample site has one definition for articles (Article) and two definitions for images (Image and ArticleImage). You can create as many flex definitions as you need. For example, a news site that should offer sports and weather articles will require a flex definition asset for sports and a different flex definition asset for weather.

Individual flex assets can be created according to only one flex definition asset. You could not create an image that used both the Image definition and the ArticleImage definition, but you can create an image that uses the Image definition and then create a different image that uses the ArticleImage definition.

A flex asset has not only the attributes assigned directly to it when it was created, it also has the attributes that it inherits from a parent. It can have multiple flex parents and whether the parents have parents depends on the hierarchical structure that you design. The following figure shows an example of a site that has three levels of hierarchy.

Figure 4-4 Levels of Hierarchy

Description of "Figure 4-4 Levels of Hierarchy"

The Other Compact Fluorescent product parent has a parent of its own (Compact Fluorescent) and several children (10576, 10578, and so on).

Flex Families and the Database

Each asset type in a flex family has several database tables. For example, the flex asset member has six tables and a flex parent type has five. This data model enables the flex member in a flex family to support more fields than an asset type in the basic asset model can support.

The four most important types of tables in the flex model are as follows:

The primary table for the asset type.
The _Mungo table, which holds attribute values for flex assets and flex parent assets only.
The MungoBlobs table, which holds the values of all the flex attributes of type blob.
The _AMap table, which holds information about the inheritance of attribute values for flex asset and flex parents only.

There are several other tables that store supporting data about the relationships between the flex assets and additional configuration information (details about search engines, the location of foreign attributes, publishing information, and, if revision tracking is enabled, version information).

Additionally, certain kinds of site information are held in the same tables that basic assets use. For example, the AssetPublication table specifies which content management sites the asset type is enabled for.

When you develop the templates that display flex assets, you code elements that extract and display information from the _Mungo tables and the MungoBlobs table.

Default Columns in the Flex Asset Type Database Table

As do basic asset types, each of the flex asset types has a primary storage table that takes its name from the asset type. For example, the primary table for the avisports sample site asset type named article is AVIArticle and the primary table for this sample site's image asset type is AVIImage. The primary table for both article and image attributes is called ContentAttribute.

Unlike the primary table for a basic asset type, the primary table for a flex asset type has only the default columns. This is because flex asset types that have attribute values do not store those values in the primary table, attribute values are stored in the _Mungo table for the asset type.

In general, the default column types in the primary table for a flex asset type are the same as the default columns in the primary storage table for a basic asset type. For the general list of default column types, see Default Columns in the Basic Asset Type Database Table.

However, there are, of course, exceptions and additions, as described in the following table:

Table 4-5 Default Columns in the Flex Asset Type Database Table

Column	Description
`category`	Category is not used in the flex asset model so there is no `category` column in any of the primary tables for flex asset types. Flex assets have no need for the category feature because queries for flex assets are based on the values of their flex attributes.
`template`	Only the table for the flex asset member in a flex family, product, article (flex), and image (flex), for example, holds values in this column. This is because only the flex asset member in the family can have a Template asset assigned to it and be displayed on your online site.
`renderid`	Holds the object ID of the Template asset assigned to a flex asset.
`attributetype`	An additional column in the primary table for flex attribute types. It holds the name of the attribute editor that formats the input style of the attribute when it is displayed in the New and Edit forms (if there is one).
`flextemplateid`	An additional column in the primary table for a flex asset type (the flex asset member of a flex family.) It holds the ID of the flex definition that the flex asset was created with.
`flexgrouptemplateid`	An additional column in the primary table for flex parent asset types. It holds the object ID of the parent definition that the flex parent asset was created with.

The _Mungo Tables

The flex asset and flex parent asset types have an AssetType_Mungo table, where AssetType is the name of the flex asset type (and matches the name of the main storage table). Its purpose is to store the attribute values assigned to an asset when an asset of this type is created. For example the avisports sample site table AVIArticle_Mungo holds the attribute values for article assets and the table AVIImage_Mungo holds the attribute values for the image assets.

Each attribute value has a separate row.

Each row in _Mungo table has a value in each of the columns described in Table 4-6.

Table 4-6 _Mungo Table Rows

Column	Description
`id`	A unique ID for each attribute value, automatically generated by WebCenter Sites when the flex asset is saved and the row is created. This is the table's primary key.
`ownerid`	The ID of the flex asset that the attribute value belongs to. (From the flex asset table: `Product`, for example.)
`attrid`	The ID of the attribute. (From the attribute table: `PAttributes`, for example.)
`assetgroupid`	If the attribute value is inherited, the ID of the parent who passed on the value. (From the parent table: `ProductGroups`, for example.)

Each row in a _Mungo table also has all of the columns in Table 4-7, but it has a value (data) in only one of them, depending on the data type of the attribute.

Table 4-7 _Mungo Table Columns

Column	Description
`floatvalue`	If the attribute's data type is `float`, the value of the attribute.
`moneyvalue`	If the attribute's data type is `money`, the value of the attribute.
`textvalue`	If the attribute's data type is `textvalue`, the value of the attribute.
`datevalue`	If the attribute's data type is `date`, the value of the attribute.
`intvalue`	If the attribute's data type is `int`, the value of the attribute.
`blobvalue`	If the attribute's data type is `blob`, the ID of the row in the `MungoBlobs` table that holds the value of the attribute.
`urlvalue`	If the attribute's data type is `url`, the path or url entered for the attribute.
`assetvalue`	If the attribute's data type is `asset`, the ID of the asset.
`stringvalue`	If the attribute's data type is `float`, the value of the attribute.

Because the _Mungo tables have URL columns (see Indirect Data Storage with the WebCenter Sites URL Field), a default storage directory (defdir) must be set for it. You use the cc.urlattrpath property in the wcs_properties.json file to set the defdir for your _Mungo tables.

The MungoBlobs Table

There is one MungoBlobs table. It holds all the values for all flex attributes of type blob, for all the flex attribute types in your system. Each attribute value has a separate row in the table.

The _AMap Tables

Flex asset and flex parent asset types have an AssetType _AMap table. Its purpose is to map the asset to the attributes it inherits from its parents. Then when you create a template that displays the asset on a page in your online site, you can query for assets based on any of their attributes and display any of those attributes, whether they were inherited or were directly assigned.

The _AMap table has one row for each flex asset that has a value for the inherited attribute. (However, if an attribute has multiple values, the _Mungo table has a row for each value.)

An _AMap table has the columns described in Table 4-8.

Table 4-8 _AMap Table Columns

Column	Description
`id`	A unique ID for each row, automatically generated by WebCenter Sites when the flex asset is saved and the row is created. This is the table's primary key.
`inherited`	The ID of the parent the attribute was inherited from, if it was inherited. (From the parent table: ProductGroups, for example.)
`attributeid`	The ID of the attribute. (From the attribute table: PAttributes, for example)
`ownerid`	The ID of the flex asset that the attribute value belongs to. (From the flex asset table: Product, for example.)

Assetsets and Searchstates

assetsets display assets, and searchstates identify which flex assets should be displayed in anassetset.

Assetset

An assetset is a group of flex assets or flex parent assets only, not flex attributes or flex definitions or flex parent definitions. For example, in the avisports sample site, you can create assetsets that contain articles and images. When coding your site pages, you code statements that create assetsets and then display the assets in them.

Searchstate

You identify which flex assets should be in an assetset by using the SEARCHSTATE method family in the templates for your flex assets. A searchstate is a set of search constraints that are applied to a list or set of flex assets. A constraint can be either a filter (restriction) based on the value of an attribute or based on another searchstate (called a nested searchstate).

A searchstate can search either the _Mungo tables in the database or the attribute indexes created by a search engine. This means that you can mix database and rich-text (full-text through an index) searches in the same query.

Because these tags search only the _Mungo table or attribute indexes for that flex asset type, using them to extract your flex assets is much more efficient than using the ASSET tags or the query asset.

Assetsets and Attribute Asset Types

WebCenter Sites cannot perform searches across attribute asset types. Because assetsets are created on the basis of attribute values, only assets that share the same attribute asset type can be included in the same assetset. This is an important point to consider when you design your flex families: data is separated for flex asset types that do not share a common attribute asset type. By creating such flex asset types you ensure that assets from different types cannot be included in a common assetset. And displaying assetsets is the mechanism for displaying flex assets on your delivery system.

For example, you can have two types of flex assets in the same flex family. While they use the same type of attributes, you can create assetsets that include assets of both types. Keep in mind, though, that a search across two types of flex assets creates a join between their _Mungo tables, which can deprecate performance.

In the avisports sample site there are two flex asset types: article and image. They share the same attribute asset type (ContentAttribute). This shared attribute asset type enables them to be included in the same assetset, even though they are two different flex asset types.

Search Engines and the Two Asset Models

Basic and flex asset models interact with search engines differently from each other because of the differences in their data structure. You’ll use a different method in each model to index asset type fields for search.

A basic asset type is defined by an asset descriptor file. Its primary storage table includes all of its properties as columns. To specify which fields of a basic asset type should be indexed, you must customize certain elements for the asset type. See Designing Basic Asset Types.
Because fields for flex assets are flex attributes, which are assets, you decide which fields are indexed for rich-text search, attribute by attribute. Additionally, the WebCenter Sites application enables you to specify which attributes should be indexed with the Search Engine field on the attribute's New and Edit forms. You do not have to customize any elements to enable this feature.

Tags and the Two Asset Models

The assets you create and manage, ultimately you move them to the delivery system where the code in the elements extracts the assets from the database and display them to your site visitors. The WebCenter Sites applications offer various toolsets, custom tag sets, in both XML and JSP to help extract assets from the database.

The toolset you use to extract assets from the database in your templates depends on the kind of asset that you are working with.

For assets with the basic asset model, use the ASSET method family.
For the flex asset member in a flex family, use the ASSETSET and SEARCHSTATE method families. Note that you should not use the ASSET.LOAD tag for the flex asset member in a flex family (product, article, and image, for example). Using ASSET.LOAD tag for flex assets is extremely inefficient because it retrieves all of the information for that asset from all of its tables. The SEARCHSTATE methods queries only the _Mungo table for the asset type of the flex asset and the MungoBlobs table.
For recommendation assets, use the COMMERCECONTEXT method family.

There are many more method families available with these products and an extensive set of custom tags from WebCenter Sites itself and several APIs.

For information about WebCenter Sites tags, see the Tag Reference for Oracle WebCenter Sites Reference.

Summary: Basic and Flex Asset Models

While the basic and flex models are quite different from each other, they are similar, too, in some ways.

The similarities and differences between the two asset models are as follows:

Where the Asset Models Intersect

Even though there are many differences in the way that the basic and flex asset models function, there are several points of intersection.

No matter which asset model you are using, basic or flex, you use the template and page asset types that are delivered with the WebCenter Sites application.
All asset types have a status code, which means that all assets, whether they are flex or basic, can be searched for with queries based on status.
All asset types, whether they are flex or basic, have the following configuration or administrative traits in common:
- They must be enabled by site.
- They must have start menu items configured for them before anyone can create individual instances of those types.
- Individual instances of them can be imported with the XMLPost utility.

Where the Asset Models Differ

Table 4-9 summarizes the major differences between the asset models.

Table 4-9 Major Differences Between the Asset Models

Feature	Basic Asset Model	Flex Asset Model
Number of database tables	One.	Several.
Adding fields to an asset type	Requires a schema change.	Does not require a schema change.
Links to other assets	Through associations and unnamed relationships.	Through flex family relationships.
Subtypes	Usually available through the Subtype item on the Admin tab. See Subtype.	Through flex definitions and flex parent definitions.
Search engine indexing	Must customize certain elements for the asset type.	Use the Search Engine field in the flex attribute form.
Main tag families	`ASSET`, `SITEPLAN`, and `RENDER`.	`ASSETSET`, `SEARCHSTATE`, and `RENDER`.
Publishing methods	Export to Disk. Mirror to Server.	Export to Server is possible, but is atypical for the flex model. Mirror to Server.