dotCMS provides multiple different ways to develop code and extend your sites. It is helpful to understand the different ways you can code in and extend dotCMS when planning your site development.
Development Type | Code Language(s) | Execution Location |
---|---|---|
Client-Side Web Development | HTML, CSS, and Javascript | Client (app or browser) |
Server-Side Web Development | Velocity | Server |
External Application Development (Headless/Content-as-a-Service/CaaS) | REST API | Server |
Plugins | Java | Server |
Combined Development | Two or more of the above | Mixed |
Client-Side Web Development: HTML, CSS, and Javascript
You may use standard client-side development methods supported by your applications or your users' browsers, such as HTML, CSS, and Javascript (including jQuery and other Javascript frameworks).
These types of code are passed directly from dotCMS to the client, without processing on the dotCMS server. Therefore the only limitation on the use of these methods are those imposed by the client browsers and applications you wish to support.
Server-Side Web Development: Velocity
dotCMS natively supports the Apache Velocity language, which is a server-side coding language that is easy to learn and use, with a simple syntax, but also easily extended with Java plugins. dotCMS both provides standard Apache Velocity classes (called Viewtools), and enables you to easily pull, manipulate, and display dotCMS content using Velocity.
In addition, you may make your Java classes and methods (and even all dotCMS supplied Java classes and methods) accessible via Velocity in the form of a Velocity Viewtool.
For more information, please see the Velocity Scripting section, or our recommendations on Velocity best practices.
External Application Development (Headless/Content-as-a-Service/CaaS): REST API
dotCMS provides a large number of REST API Endpoints which can be used to create, modify, and access dotCMS objects and content. Almost all functionality available via the dotCMS back-end can be performed using one of the dotCMS REST APIs, enabling you to create your own applications to access all the same content and duplicate most of the operations of the dotCMS back-end.
For more information on the dotCMS REST API, please see the REST API documentation.
You may also create your own custom REST endpoints using Scripted Custom Endpoints. These endpoints can access all functionality available via Velocity code, and since Velocity code can access Java classes and methods, these custom endpoints make it easy for you to expose your own Java classes or any functionality in the dotCMS Java API through a REST API.
For more information, please see the Scripted Custom Endpoints documentation.
Plugin Development: Java
You may create both static and dynamic OSGI plugins to extend dotCMS functionality. Plugins are coded in Java. Dynamic plugins can be loaded and unloaded without restarting your dotCMS server. Static plugins may not be dynamically loaded, but can be used to perform some types of changes that can not be performed with dynamic plugins (such as overriding built-in dotCMS classes).
Combining Development Methods
You may combine any or all of these methods however you wish to provide the level of control, performance, and security required for your application. For example, you may create a Javascript form which runs on the client, but which calls a REST API endpoint to retrieve and update data in the dotCMS content repository. You may also create a Java plugin and expose the classes in your plugin as Velocity Viewtools to extend your Server-side web development capabilities.
However it's important to note that when mixing client-side and server-side code, the server-side code always runs first, and then the client-side code runs. You can not pass the results of client-side code to server-side code (e.g. you can not pass the results of Javascript code to Velocity). If you need to pass the results of client-side code to be processed on the dotCMS server, it is recommended that you do it through a mechanism which directly queries the dotCMS server, such as a Scripted Custom Endpoint, or a REST API call to process Velocity code.
For more information on each of these development methods, please see the appropriate documentation section.