This chapter will provide you explanations about some technical terms that we use throughout the documentation.

* *Container Template*: Templates are used to contain UI components in a specific layout and display them on the portal page.
* *ConversationState*: The *ConversationState* object stores all information about the state of the current user. This *ConversationState* object also stores acquired attributes of an Identity which is a set of principals to identify a user.
* *Data container*: Data container implements the physical data storage. It enables different types of backend (like RDB, FS files, etc) to be used as a storage for JCR data. With the main Data Container, other storages for persisted Property Values can be configured and used. eXo JCR persistent data container can work in two configuration modes.
** *Multi-database*: One database for each workspace (used in standalone eXo JCR service mode).
** *Single-database*: All workspaces persisted in one database (used in embedded eXo JCR service mode, e.g., in eXo portal).
The data container uses the JDBC driver to communicate with the actual database software, for example, any JDBC-enabled data storage can be used with eXo JCR implementation.
* *Database Creator*: Database creator (DBCreator) is a service that is responsible for executing DDL (Data Definition Language)script in runtime. A DDL script may contain templates for database name, username, and password which will be replaced by real values at execution time.
* *Drives*: A drive is a customized workspace with:
** a configured path where the user will start when browsing the drive.
** a set of views that allow limiting the available actions, such as the edition or creation of contents while being in the drive.
** a set of permissions to limit the access (and view) of the drive to a limited number of people.
** a set of options to describe the behavior of the drive when users browse it.
* *eXo Cache*: All applications on the top of eXo JCR that need a cache, can rely on an _org.exoplatform.services.cache.ExoCache_ instance managed by the _org.exoplatform.services.cache.CacheService_.
* *eXoContainer*: eXoContainer behaves like a class loader that is responsible for loading services/components. The eXoContainer class is inherited by all the containers, including RootContainer, PortalContainer, and StandaloneContainer. It itself inherits from a PicoContainer that is a framework which allows eXo to apply the IoC Inversion of Control principles. 
* *External Plugin*: The External Plugin allows adding configuration for services and components easily.
* *Folksonomy*: A folksonomy is a system of classification derived from the practice and a method of collaboratively creating and managing tags to annotate and categorize content. This practice is also known as collaborative tagging social classification social indexing and social tagging. (Source: http //en wikipedia org).
* *Gadget*: Gadgets are web-based software components based on HTML, CSS, and JavaScript. They allow developers to easily write useful web applications that work anywhere on the web without modification. (Source: opensocial.org)
* *Groovy template*: This template is widely used in eXo UI framework. It leverages the usage of Groovy language, a scripting language for Java. The template file consists of HTML code and groovy code blocks.
* *JCR WebDav*: JCR WebDav is a service that allows a JCR repository to be accessed via WebDav.
* *JobSchedulerService*: JobschedulerService defines a job to execute a given number of times during a given period. It is a service that is in charge of unattended background executions commonly known for historical reasons as batch processing. 
* *JodConverter*: JodConverter (Java OpenDocument Converter) is a tool that converts documents into different office formats and vice versa.
* * JCR Item*: JCR Item can be a node or a property.
* *ListenerService*: Inside eXo, an event mechanism allows triggering and listening to events under specific conditions. This mechanism is used in several places in eXo, such as login/logout time, create/update users, and groups.
* *LockManager*: LockManager stores lock objects so it can give a lock object or can release it. Also, LockManager is responsible for removing Locks that live too long. 
* *Namespace*: The name of a node and property may have a prefix delimited by a single ':' colon character that indicates the namespace of the item.(Source JSR 170). Namespace is used to avoid naming conflict. 
* *Navigation node*: A node is like a label of the link to page on the Navigation bar. By clicking a node, the page content is displayed. A node maps a URI and a portal page for the portal's navigation system. 
* *Navigation*: A navigation which looks like a menu is to help users visualize the site structure and to provide hyperlinks to other parts on a Portal. Thus a bar which contains navigations is called the Navigation bar. 
* *Node type*: A node type defines which child nodes and properties a node may (or must) have. Every node type has attributes, such as name, supertypes, mixin status, orderable child nodes status, property definitions, child node definitions and primary item name.(Source: JSR 170). 
* *Node*: Node is an element in the tree structure that makes up a repository. Each node may have zero or more child nodes and zero or more child properties. There is a single root node per workspace which has no parent. All other nodes have only one parent. 
* *Organization listeners*: The OrganizationService provides a mechanism to receive notifications via an organization listener, including UserEventListener, GroupEventListener and MembershipEventListener. 
** UserEventListener is called when a user is created, deleted or modified.
** GroupEventListener is called when a group is created, deleted or modified.
** MembershipEventListener is called when a membership is created or removed.
* *Organization management*: It is a portlet that manages users groups and memberships. This portlet is often managed by administrators to set up permission for users and groups. 
* *OrganizationService*: OrganizationService is a service that allows accessing the Organization model. This model is composed of users, groups, and memberships. It is the basis of eXo's personalization and authorizations and is used to all over the platform. 
* *Path constraint*: A path constraint restricts the result node to a scope specified by a path expression. The following path constraints must be supported exact child nodes descendants and descendants or self. (Source: JCR 170). 
* *Permission*: The permission settings control which actions users can or cannot perform within the portal and are set by the portal administrators. Permission types specify what a user can do within the portal. 
* *Portal Page*: A portal page can consist of one or more various portlets. Their layout is defined by container templates. To display a portal page, this page must be mapped to a navigation node. 
* *Portal skin*: Portal skins are graphic styles that display an attractive user interface. Each skin has its own characteristics with different backgrounds, icons, color, etc. 
* *PortalContainer*: This kind of container is created at the startup of the portal web application in the init method of the PortalController servlet. 
* *Portlet*: A portlet is a web-based application that provides a specific piece of content to be included as part of a portal page. In other words, portlets are pluggable user interface components that provide a presentation layer to information systems. There are two following types of portlet:
** *Functional Portlets*: support all functions within the portal. They are integrated into the portal that can be accessed through toolbar links.
** *Interface Portlets*: constitute the interface of a Portal. eXo Portal consists of some Interface Portlets, such as Banner Portlet, Footer Portlet, Homepage Portlet, Console Portlet, Breadcrumb Portlet and more. 
* *Property constraint*: A query may specify further constraints on the result nodes by way of property constraints. (Source: JCR 170). 
* *Property*: Property is an element in the tree structure that makes up a repository. Each property has only one parent node and has no child node. 
* *Repository*: A content repository holds references to one or more workspaces. 
* *REST framework*: eXo REST framework is used to make eXo services (for example, the components deployed inside eXo Container) simply and transparently accessible via HTTP in a RESTful manner. In other words, those services should be viewed as a set of REST Resources-endpoints of the HTTP request-response chain. Those services are called *ResourceContainers*. 
* *RootContainer*: *RootContainer* is a base container. It plays an important role during startup but it is recommended that it should not be used directly.
* *RTL Framework*: RTL Framework (Right To Left Framework) is a framework that handles the text orientation depending on the current locale setting. It consists of four components, including Groovy template, Stylesheet, Images, and Client java.
* *StandaloneContainer*: *StandaloneContainer* is a context independent eXo Container. It is also used for unit tests.
* *Taxonomy*: Taxonomies are used to sort documents in order to ease searches when browsing documents online.
* *Tree structure*: Tree structure is defined as a hierarchical structure with a set of linked nodes and properties.
* *Type constraint*: A type constraint specifies the common primary node type of the returned nodes plus possibly additional mixin types that they also must have. Type constraints are inheritance-sensitive in which specifying a constraint of node type x will include all nodes explicitly declared to be type x and all nodes of subtypes of x. (Source: JSR 170).
* *Web Content*: Web Content is the textual, visual or aural content that is encountered as part of the user experience on a website. It may include other things such as texts images sounds videos and animations. 
* *Workspace*: is a container of a single rooted tree that includes items. 

