Chapter 1

Introducing the Sitecore ASP.NET CMS

What's in This Chapter?

Reviewing web content management systems

Separating content management environments

Sitecore product and company history

Identifying Sitecore solution components

This chapter explains the purpose of a web content management system (CMS), describes the separation of CMS environments, such as test and production, and provides an overview of Sitecore — both the company and its namesake ASP.NET (Application Server Pages with the .NET Framework) CMS, as well as the history of that product. Finally, this chapter describes the components that comprise a Sitecore instance, which is an installation of the Sitecore ASP.NET CMS product.

Web content management software enables nontechnical CMS users to maintain the content driving a web solution without the need to understand its technical implementation. Sitecore uses the ASP.NET platform provided by the Internet Information Server (IIS) web server on the Microsoft Windows operating system to provide one of the most advanced and comprehensive web content management solutions and development frameworks available today.

No web content management system delivers the solution you need without some level of input, whether in the form of entering content and choosing predefined presentation components or building an entire solution. While predefined presentation components are available for the platform, Sitecore is on the latter end of this continuum, focusing on CMS developers as much as users, providing both a finished product and a development framework.

Understanding Web Content Management Systems

Web content management systems are typically web applications that provide browser-based user interfaces for users within an organization (CMS users) to maintain the content and often some aspects of the presentation of one or more published websites. Web content management systems typically depend upon a web server and an application server or the Common Gateway Interface (CGI — see http://bit.ly/tvN7Vg). Individual content management systems provide additional specific features such as authentication, authorization, locking, versioning, workflow, audit, internationalization, and localization of the content, as well as separation of work-in-progress data from the published websites.

Web content management systems typically store structured, unstructured, and binary content. Presentation components of the system format that content as markup, such as HTML, for clients such as web browsers. That markup typically contains embedded links to media and other resources in the CMS. One primary aim is to enable nontechnical subject matter experts to maintain the content of websites without having to learn technologies such as HTML or install client-side software. Additional goals typically include consistency in the presentation of the published websites, as well as reuse of content among pages and multiple managed sites, as well as formatting that content differently for various devices (different markup for browsers, mobile devices, printers, and so forth), or content reuse for any other purpose.

There are two primary types of web content management systems. In the early days when web servers and web application servers were not tightly integrated (think CGI), the first CMS tools merged content with code in some kind of generation process run in a content management environment and then published the result to a content delivery environment as files. That result could be static markup to serve without processing (which generally required a separate architecture to manage web applications as opposed to static pages) or code to process further at runtime using a web application server. More advanced solutions stored information in database records in addition to or instead of files, often using query string parameters or other URL components to identify those records.

As application servers became more common, and especially as ASP.NET merged the application server with the web server, content management systems evolved to generate output dynamically for each HTTP request. These modern systems merge content with presentation at runtime to generate each page. While publishing static files can have some benefits, the advantages of generating output at runtime become more clear as the Internet evolves further into a dynamic, integrated, social experience personalized for each visitor.

Due in part to the incredible pace of change on the web, no CMS software can possibly generate your site automatically, or even meet all of your current expectations, let alone your potential future requirements. In fact, requirements typically change between platform selection and the time the website becomes available to public visitors. A website may have a shelf life of just a few years before it begins to appear stale, and organizations frequently acquire other organizations or go through other rebranding exercises. The solution architecture must be flexible enough to support new features and visual redesign. Consider a CMS as a development platform or framework rather than a canned solution. Think of CMS implementation as an ongoing program, not a project with a fixed duration.

Content management solutions typically involve a number of technical environments. Developers often install Sitecore on their workstations, though some organizations employ a shared development environment for multiple developers. From there, code changes should go through at least an integration test environment and then additional environments such as user acceptance testing (UAT). When complete, changes arrive in the content management production environment, where CMS users update the site; and from content management production to content delivery, where visitors access the published website. Some organizations deploy changes to a staging environment before they reach content management production and content delivery.

As opposed to code changes initiated by developers, content changes often go through a separate publishing workflow process initiated by CMS users in the production content management environment.

Therefore, there are actually two production environments: production content management and production content delivery. Content delivery is the most critical environment; if that environment is down, the published website is down. If the production content management environment is down, CMS users cannot update the site.

Introducing Sitecore

Sitecore is a complete ASP.NET development platform and web content management system (CMS). Sitecore is the leading ASP.NET web CMS available worldwide today. Its unique open architecture, diverse capabilities, and extensibility make it the most advanced CMS on the market. Sitecore developers generally agree that they can deliver more value on their projects in less time using the Sitecore product suite than using any other system.

Sitecore is a high-performance, scalable, extensible ASP.NET web CMS that generates all output dynamically and uses the same components and system architecture for both content and application pages. Sitecore does not limit the markup you can generate or the technologies that you can use, such as XHTML (eXtensible HyperText Markup Language), HTML5, CSS Cascading Style Sheets (CSS), and Asynchronous JavaScript and XML (AJAX).

The Sitecore CMS provides at least the following array of facilities for managing complex and dynamic websites:

Flexible, hierarchical data storage

APIs and points of configuration and extension, including hooks into the user interface, pipelines, event handlers, and much more

A layout engine that dynamically assembles and caches ASP.NET control trees, making it easier to implement a consistent solution by reusing code and content than an inconsistent solution by cutting and pasting

The concept of devices, which enable different presentations of individual content items under varying conditions

Security, including authentication, authorization, role, and profile management based on ASP.NET membership providers

Workflow and separation of unpublished content from published content

Visual comparison of differences between versions of field values

A media library for managing binary assets

A rules engine for browser-based configuration of dynamic logic

Optional modules for additional functionality, most importantly the Digital Marketing System (DMS) described in Chapter 10

Developer tools such as the free Sitecore Rocks extension for Microsoft Visual Studio

Sitecore keeps content and presentation separate until runtime, when it merges the two based on the context of the user (their personal profile and access rights), the request (the content item identified from the requested URL), and potentially other criteria such as the type of device that requested the page. Based on this information, the layout engine assembles a hierarchy of presentation controls, and then determines whether to execute each or retrieve output cached previously under equivalent processing conditions.

You can think of Sitecore as providing an extension to ASP.NET itself, including browser-based user interfaces, abstract data storage facilities, complete application programming interfaces (APIs), and opportunities for configuration, extension, and customization.

Logging In

To log in to Sitecore, access the URL /sitecore on a Sitecore instance in one of the browsers supported by Sitecore (generally, a current version of Microsoft Internet Explorer, Google Chrome, Mozilla Firefox, or Apple Safari (see the Sitecore Installation Guide at http://bit.ly/pv7X3B for information about supported browsers in your version of Sitecore). For example, the URL of the login page for the instance of Sitecore that I used while writing this book is http://sitecorebook/sitecore.

If you previously logged in with the Remember Me option, accessing /sitecore may not take you to the Sitecore login page, instead taking you directly into a Sitecore user interface. In this case, you can access the login page at /sitecore/login.

To select one of the Sitecore user interfaces, click Options. Figure 1.1 shows the Sitecore login page.

Figure 1.1

This book assumes that you are familiar with all three CMS user interfaces available from the Sitecore login page:

The Page Editor (see Figure 1.2), for nontechnical content contributors.

The Content Editor (see Figure 1.3), for more advanced content managers.

The Sitecore desktop (see Figure 1.4), for administrators, advanced content managers, and developers. The image shown in Figure 1.4 appeared after clicking the Sitecore button ⇒ Development Tools ⇒ Keyboard Map, which provides some context by opening the Keyboard Map application.

The Sitecore desktop functions like a windowing operating system, but runs in a browser. In this book, the term desktop generally refers to the Sitecore browser-based desktop unless otherwise indicated, such with the phrase Windows desktop.

Figure 1.2

Figure 1.3

Figure 1.4

Many of the instructions in this book require that you use the Content Editor. To launch the Content Editor, use a browser to access the Sitecore login screen at /sitecore. For example, if the URL of the Sitecore instance is http://sitecorebook, access http://sitecorebook/sitecore. Figure 1.1 shows the Sitecore login screen.

You can use the Content Editor as a standalone application, or you can use the Content Editor within the Sitecore desktop. To choose between these approaches, click Options on the Sitecore login screen. Login options appear on the login screen as shown in Figure 1.5.

Figure 1.5

Enter your authentication credentials. To use the Content Editor as a standalone application, double-click Content Editor. The Content Editor appears as shown in Figure 1.6.

Figure 1.6

Alternatively, to use the Sitecore desktop, enter your authentication credentials and double-click Desktop on the Sitecore login screen. The Sitecore desktop appears as shown in Figure 1.7.

The photograph shown in Figure 1.7 is of a lighthouse at the Danish Trekroner Fort (see http://bit.ly/ABmTge). Sitecore initially developed and continues to engineer much of the CMS in Denmark. Sitecore desktop background images distributed with the CMS are similar to the desktop background images provided with the Microsoft Windows operating system, but are intended for use within the Sitecore browser-based desktop.

Figure 1.7

Click the Sitecore button in the lower-left corner of the Sitecore desktop. The Sitecore menu appears as shown in Figure 1.8.

Figure 1.8

Click Content Editor. The Content Editor appears within the Sitecore desktop as shown in Figure 1.9.

Figure 1.9

Embedded Applications

From within each of the Sitecore user interfaces, and especially from within the Sitecore desktop, you can access additional Sitecore applications. These applications include the following:

Marketing Center — Configure marketing programs and tracking elements to help understand who is visiting the site, what brought them there, and which programs and content are most engaging.

Media Library — The Media Library is just the Content Editor with the Media Library tab selected, exposing a repository for binary assets such as images and video.

I am not aware of any task that you can perform in the Media Library that you cannot accomplish by navigating to the /sitecore/media library branch in the Content Editor. Due to (arguably) better usability, some users may prefer to access the Media Library to work with media items rather than the Content Editor.

Engagement Analytics — Measure the effectiveness and efficiency of your website and marketing programs (requires the Digital Marketing Suite, or DMS).

Executive Dashboard — Assess from a high level how marketing channels, traffic sources, and campaigns perform (requires the Digital Marketing Suite, or DMS).

Security Editor — Apply access rights to items for users and roles.

Template Manager — The Template Manager is simply the Content Editor rooted at the /sitecore/templates item.

I am not aware of any task that you can perform in the Template Manager that you cannot achieve by navigating to the /sitecore/templates branch in the Content Editor. Due to (arguably) better usability, some developers may prefer to access the Template Manager to work with data templates rather than the Content Editor.

Sitecore App Center — Configure and manage email, social media monitoring, Windows Azure hosting, search engine optimization (SEO), translation, standards compliance, and other cloud-based services.

Preview — View the site as its content may have appeared at a point in the past or as it may appear at a point in the future.

Debugger — Activate the Sitecore browser-based debugger to analyze your pages and their performance.

Carousel — Visually analyze internal links between items.

Recycle Bin — Review and restore deleted items.

Search — Search the content database.

Workbox — Manage active workflow processes.

Control Panel — Manage system and personal configuration options.

Access Viewer — Review effective security access rights.

Domain Manager — Manage security domains.

Role Manager — Manage security roles.

User Manager — Manage CMS users and identifiable visitors of the published sites.

Developer Center — Use a browser-based integrated development environment (IDE) to manage layouts, sublayouts, XSL renderings, and other development resources.

When possible, use Microsoft Visual Studio, especially with Sitecore Rocks, in favor of the Developer Center.

Package Designer — Create packages for migrating components from one Sitecore environment to another.

Installation Wizard — Install packages created with the Package Designer.

File Explorer — Navigate the document root filesystem of the IIS website hosting the Sitecore solution.

Keyboard Map — Collect codes for use in keyboard shortcuts.

Log Viewer — View Sitecore log files.

Broken Links — Manage broken internal links.

Additionally, specific Sitecore user interfaces often contain further embedded interfaces. For example, when you select a definition item for a data template in the Content Editor or the Template Manager, Sitecore displays the Template Builder, which is a custom editor for items based on that data template. For more information about data templates, see Chapter 2.

This book assumes that you have some familiarity with each of these user interfaces, or can quickly learn to use them with minimal instruction and no screen shots. By following the Microsoft Windows and Office UI conventions wherever possible, Sitecore user interfaces support usability through familiarity and discoverability, and provide for application configuration at both the role and user levels.

Working with Sitecore

Sitecore is an ASP.NET application that uses the same architecture and APIs that you use to develop solutions with Sitecore: the Sitecore user interfaces are in fact a website managed with Sitecore. It can take some time to adjust to this concept, so to say it another way, Sitecore uses the same technologies and its own APIs to build the CMS user interfaces that you use to build solutions with Sitecore. This benefits Sitecore developers who need to customize the Sitecore user interfaces by lowering the amount of API knowledge required to achieve such objectives.

With Sitecore, URLs on the published websites often do not correspond to files under the document root or in a virtual directory on the web server, but to items (records) in a relational database that indicate what presentation components the layout engine should use to process HTTP requests that specify those items. While mapping URLs to files can have some benefits, mapping URLs to items in a data store has tremendous value in terms of content and presentation component reusability.

Because Sitecore is a development framework, you can implement an information architecture and presentation components to generate output in any way you want. Sitecore does not provide data structures or presentation components to capture and present your solution; you use Sitecore to implement these components to deliver the exact solutions needed. The platform is incredibly flexible, providing comprehensive validation and other features that you can configure and extend to meet almost any foreseeable requirements. Sitecore's robust combination of architecture, flexibility, efficiency, and, most important, usability, reduces the risk that a web solution might not reach production or achieve user adoption, and increases the project's potential return on investment (ROI).

Sitecore provides additional software such as the Digital Marketing Suite (DMS) for advanced experience management, personalization, and web analytics, as well as additional software products and services that work with its web content management system. These include an Intranet management product, the Foundry product for dynamically syndicating numerous similar websites, e-commerce products, a framework for integrating Sitecore with Microsoft SharePoint, and numerous others as described in Chapter 10.

Sitecore Company History

After working together extensively on numerous technical and other projects in and out of school, six Copenhagen University graduates founded Sitecore in 2001. Sitecore focused on its ASP.NET web content management system as its core competency, building a partner channel to deliver consulting and entire solutions to its customers. Sitecore quickly capitalized on the rise of ASP.NET from the ashes of classic ASP (Application Server Pages without .NET) and the foibles of Java and missteps of several Java-based CMS platforms, outcompeting large vendors in established markets and expanding worldwide.

Even in difficult global economic conditions, Sitecore continues to announce record business performance, including an impressive number of new customers every month. Sitecore now has more than 390 employees around the world, primarily in research, development, and innovation, and more than 750 partners that function as an extension of the organization. Thousands of organizations use Sitecore to manage tens of thousands of websites, and approximately 15,000 users can access the Sitecore Developer Network (SDN — http://sdn.sitecore.net).

Sitecore ASP.NET CMS Version History

When I joined Sitecore in the summer of 2004, the current distribution of Sitecore CMS was version 4.3.2.x. I would not have joined Sitecore if my research had not lead me to believe it was the best CMS available at the time, and I think Sitecore 4.x would probably still be a viable CMS for many projects.

Sitecore CMS 5.0 through 5.3 replaced the Sitecore 4 concept of layout groups with the concept of devices, replaced a simple version approval checkbox with advanced workflow capabilities, added the extranet, security, core, archive, and Recycle Bin databases, and introduced the Sitecore desktop, built with new Sitecore UI technology. Possibly most important for developers, Sitecore CMS 5 provided a consolidated API for both the CMS and the published websites, whereas Sitecore 4 had separate APIs for each. With Sitecore CMS 5, Sitecore introduced the current Sitecore Developer Network.

Sitecore CMS 6.0 introduced standard values, branch templates and command templates (all of which eliminated the need for the concept of masters used to instantiate new items in earlier Sitecore versions). Sitecore 6 improved usability and performance in the Content Editor, replaced WebEdit (with the circular content markers) with the Page Editor, and replaced a proprietary security implementation with ASP.NET membership providers. Sitecore 6 eliminated the Archive and Recycle Bin databases by implementing tables for these features in the content databases, and eliminated the Security and Extranet databases by moving security information to the core database.

Sitecore CMS 6.1 introduced the rules engine, added the Field Editor and Edit Frames, provided a foundation for the Online Marketing Suite (now the Digital Marketing System, or DMS), and introduced rendering parameters templates.

Sitecore CMS 6.2 added support for WebDAV (Web-based Distributed Authoring and Versioning) and the File Drop Area field type, introduced the Word Document field type, and provided support for public and Sitecore Client RSS feeds.

Sitecore CMS 6.3 improved Sitecore's architecture for horizontal scalability by introducing remote events, eliminating the staging module, supporting load balancing in the content management environment, and introducing support for Sitecore Azure to deploy solutions to the Microsoft Windows Azure Internet cloud.

Sitecore CMS 6.4 improved the Page Editor and its extensibility, updated the Telerik Rich Text Editor included with the CMS, introduced compatibility with and support for .NET 4.0 and ASP.NET MVC, provided clones, the notification engine, and layout deltas, and was the first version of Sitecore to support additional browsers in the Sitecore Desktop.

Sitecore 6.5 provided the foundation for the Digital Marketing System (DMS) and hence Customer Engagement Platform (CEP), which replaces Sitecore's Online Marketing Suite (OMS), its first platform supporting integrated web analytics. In addition to simple traffic measurement and other common web statistics, CEP supports efficient marketing and engagement automation, automatic visitor origin classification, as well as analysis of the value of each visit and the efficiency of paths through the website. In comparison to OMS, DMS provides improved scalability, greater performance, enhanced report readability, improved capabilities for real-time personalization, and high-level dashboards.

Sitecore Components

Sitecore is an ASP.NET application that provides a layer between the developer and the ASP.NET framework, including components such as databases.

Follow Microsoft best practices for Internet Information Services (IIS) and ASP.NET security, performance, and scalability, load testing, hardware requirements planning, and other administrative considerations.

A Sitecore installation consists of five basic components: some number of relational databases (three by default), a Microsoft Windows Internet Information Services (IIS) website, an application pool, a corresponding filesystem for the document root of that website, and a separate subdirectory for storing data files (technically, that subdirectory can exist within the document root). Most Sitecore solutions include a Visual Studio project, and I recommend that all Sitecore developers use the free Sitecore Rocks extension for Visual Studio. For instructions to install Sitecore, see Appendix B.

Sitecore Databases

Each Sitecore instance depends on some number of Microsoft SQL Server or Oracle relational databases. You can install the database server on the same machine as the web server. For production, you should use one or more separate, dedicated database servers to host the Sitecore databases.

You can use the free Express versions of Microsoft SQL Server and Oracle in development, test, and potentially additional non-production environments. Because you write code against a Sitecore API layer that abstracts the underlying storage mechanism, you can even use different database vendors in different environments, unless you write code that interacts directly with the database.

The three default Sitecore databases serve the following purposes:

Master — The master database contains all versions of all content, including changes not yet published to the live website. Excluding the browser-based Sitecore debugger that accesses the published website by default, CMS user interfaces access the master database by default.

Web — The web database contains the current published version of each item in each language. The web database is the default publishing target database: by default, Sitecore publishes changes from the master database to the web database. You can add additional publishing target databases as described in Chapter 9.

Core — The core database defines the Sitecore user interfaces, and controls which users can access which features of the various Sitecore applications. By default, the core database also contains the tables used by the ASP.NET security provider implementations, as well as system tables such as that used for internal link management. The managed website that provides the Sitecore user interfaces accesses the core database and allows the user to view and edit content in the master database by default.

Each of these databases contains very similar database schemas, but the core database typically contains tables for its additional default function. You can configure Sitecore to use different databases for each function.

You can sometimes add and eliminate databases, such as by adding one or more additional publishing target databases in the content management environment or by removing the master database from a content delivery environment. If you configure multiple Sitecore instances to write to a single database, to ensure appropriate cache clearing, you must enable remote event management on both instances. For more information about eliminating databases and sharing databases between instances, see The Sitecore Scaling Guide (http://bit.ly/oKvYuN).

Optional modules, including the Digital Marketing Suite (DMS) and Web Forms for Marketers (WFFM), require additional relational databases. Apply enterprise backup and optimization techniques to the Sitecore databases, including rebuilding database indexes.

Hosting IIS Websites

Sitecore requires an IIS (Internet Information Services) website with a corresponding application pool and document root to host the ASP.NET application. For more information about IIS and ASP.NET, see http://iis.net and http://asp.net, respectively.

You can use IIS to host any number of websites. IIS bindings determine which website services a request based on the hostname, port, and protocol (HTTP or HTTPS).

Technically, the root subdirectory of the website (its document root) and each subdirectory can expose an ASP.NET application, and each application can use a separate application pool. Sitecore does not support applications in subdirectories.

Sitecore can use a single IIS website to manage multiple logical websites. While IIS can manage multiple websites, including multiple instances of Sitecore with separate filesystems, each Sitecore instance can manage multiple logical websites with a common filesystem and databases.

IIS Application Pool

Each IIS website can expose an ASP.NET application, which depends on an application pool. The application pool hosts an ASP.NET application, and Sitecore is an ASP.NET application. The Sitecore setup executable creates an IIS application pool for the instance. If you install Sitecore without using the setup executable, you should manually create an application pool for each new instance.

Windows uses a process to host the application pool, typically w3wp.exe but sometimes aspnet_wp.exe. A Windows user such as Network Service or an application pool identity owns the application pool process. For information about application pool identities, configuring filesystem access rights, and other aspects of the application pool, see Appendix B.

Document Root Subdirectory

The IIS website references a document root subdirectory. By default, this subdirectory contains the Sitecore application and supporting files. Your solution files will appear in this subdirectory. The document root subdirectory contains the /web.config file that configures the ASP.NET application at that location.

As described further in this book, features including the Sitecore configuration factory support Web.config include files. Web.config include files allow you to patch the actual /web.config file. This book describes the Web.config file in relation to features that support include files, but includes a leading slash and applies a style (/web.config) when referring to the actual /web.config file itself. Web.config include files can only apply to elements within the /configuration/sitecore section.

Data Subdirectory

Sitecore uses the subdirectory specified by the dataFolder variable in the Web.config file to store data files such as its license, logs, and Lucene search indexes.

Lucene (http://lucene.apache.org) is an open-source search engine maintained by the Apache group (http://apache.org). For more information about Sitecore's use of Lucene, see http://bit.ly/rxaImG.

Sitecore Visual Studio Project

Most Sitecore solutions involve at least one Microsoft Visual Studio project. Install Visual Studio on development workstations, not on production servers. Most Sitecore developers use IIS rather than the web server built into Visual Studio. For instructions on how to create a Visual Studio project for your Sitecore solution, see Appendix B.

Sitecore Rocks

Developers working with Visual Studio and the Sitecore ASP.NET CMS should use the Sitecore Rocks (http://sitecorerocks.net) extension for Visual Studio. Most Sitecore developers use Visual Studio and can benefit greatly from this free tool from Sitecore.

Install Sitecore Rocks on the development workstations on which you install Visual Studio.

For more information about Sitecore Rocks, see my blog post at http://bit.ly/oZTaZI. For additional useful tools for Sitecore developers, see my blog post at http://bit.ly/nQHKfH.

Take Home Points

This chapter introduced web content management systems (CMS), CMS environments, the Sitecore ASP.NET CMS product, the Sitecore company, and the main components of a Sitecore installation. Sitecore developers using Visual Studio can implement advanced, scalable, consistent Sitecore solutions on the Microsoft Windows, IIS, and ASP.NET infrastructure to enable nontechnical CMS users to maintain structured content to populate a website using only a browser. Sitecore is a pure ASP.NET application, and tightly conforms to the core architectural principle of the framework.

The Sitecore solution infrastructure maximizes code and content reuse, and minimizes development and maintenance costs. It also provides a comprehensive, extensible, and flexible platform for your projects and a pleasant working environment for developers. Sitecore provides a variety of browser-based interfaces and applications for various types of users and tasks, as well as tools for developers, including the Sitecore Rocks plug-in for Visual Studio and optional software modules that integrate with the Sitecore CMS.

Chapter 2

Information Architecture

What's in This Chapter?

Creating items, including item properties, definition items, and item URLs

Using data templates, including base templates, the standard template, standard values, template sections, template fields, field properties, and field types

Considering data validation, including validators and validation options

Implementing multilingual solutions, including languages, regions, and multiple managed sites

Working with binary media, including media library settings and media item URLs

Understanding clones, aliases, and wildcards

Using insert options, including branch templates, command templates, and the uiGetMasters pipeline

This chapter introduces fundamental high-level concepts and low-level constructs and techniques used to implement and enforce information architecture with the Sitecore ASP.NET web content management system (CMS). Data templates define the structure of each type of item that you can store in a Sitecore database. Some types of items represent pages, such as the home item for each managed site. Sitecore contains logic to determine the URL for each such item, and to determine the item indicated by the URL in an incoming HTTP request. Sitecore uses items to manage numerous additional types of information, including configuration data, system components, and binary media.

Each data template defines zero or more sections that contain fields to define the structure and properties of a type of items. A data template can inherit sections and fields from any number of base templates. By default, data templates inherit from the standard template, which contains fields that define system properties available to all items. You can translate each item into any number of languages, and create any number of versions within each language. You can specify that Sitecore should not maintain versions or allow translation for the values of specific fields. Standard values define defaults (“standards”) for new items based on each data template. You can use validation to enforce data entry requirements. You can import content by invoking Sitecore Application Programming Interfaces (APIs) to create items and update field values.

Insert options control the types of items that users can create beneath existing items to define a hierarchical data structure. You can create item structures to represent websites, lookup lists, metadata taxonomies, and any other kind of data that you can structure in a hierarchy. Sitecore provides a number of facilities that enable you to share items and field values among components. You can create aliases to provide alternate URLs for items. You can create clones to make items appear in multiple locations in the content tree with the ability to override field values in the cloned items without actually duplicating those items. You can use wildcards to map URLs to resources in external repositories such as relational databases rather than items in the Sitecore database.

For more information about the topics described in this chapter, including instructions to implement the various components described, see The Sitecore Data Definition Reference (http://bit.ly/nmGuiB), The Sitecore Data Definition Cookbook (http://bit.ly/oc8F9K), and The Sitecore Data Definition API Cookbook ().

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!