Before you learn about the details of how Umbraco ultimately presents the content, take a look at what it means to separate content from structure. Umbraco has a very clear separation of tools and responsibilities when it comes to maintaining content and layout—structure, design, and media assets. Although Chapter 4 discusses the separation of layout and structure in greater detail, right now the focus is primarily on Umbraco's toolsets and interface.
The backoffice, also known as the admin user interface, is made up of sections, as shown in Figure 2-1. A section is an area of the backoffice that contains specific functionality targeted at predefined roles, such as for a developer, an editor, and the like. A set of standard sections comes with every Umbraco installation. However, given the extensibility of the Umbraco application programming interface (API) you, as a developer, can also create your own custom sections (covered in the samples starting in Chapter 15). The following discussion breaks down and covers the backoffice sections.
Each and every section within the Umbraco backoffice is made up of trees. These trees contain nodes that are made up of the various types of content—media items, content pages, users, permissions, and so on.
WHAT IS A NODE?
This book refers to the various pieces of content as nodes. These, in their respective contexts, are pages, users, folders, images, files, templates, and so on.
The benefit of dividing the interface into these sections is that now you can have multiple roles working within the same site and assign the specific sections to them that they need, or rather should, have access to. For example, a content editor and non-technical person should not have access to the Developer section, ever! If you allow that type of access, you're introducing a host of problems for yourself, including a potential site crash!
If you change a template, stylesheet, script, or XSLT macro in the backoffice, you have no way to undo that change after you have navigated away from the window/section. Also, a save to any of these files is instantaneously available to the end user (no save versus publish feature is available on styles, scripts, master pages, or XSLT files). A negligent change can cause you to end up with a trashed site. So, tread carefully.
The author advises, and discusses in detail in this book, that you do not maintain styles, scripts, masterpages, and XSLT files directly within your installation; rather, that you manage these files in a source control environment such as SVN, CVS, or Visual SourceSafe. Appendix C covers the methods and best practices of this type of file management.
In this section, you create a new user and restrict the sections to which she has access. Follow these steps: