Documentation is considered a feature in DecentCMS, and as such, it is expected that all modules come with tests, API documentation, and documentation topics. Documentation, like tests, are part of the same code repository as the rest of the application or module.
The widgets layer file can be found under
index.jsonfile describes the layers of widgets for the site. Layers are collections of widgets that can be turned on or off by an expression that is associated with each layer and that gets evaluated for each request against an environment that can be contributed to by modules, and that can use extension rules also contributed by modules. More than one layer can be active on any given page of the site.
Placement files describe how to dispatch shapes into zones. They are necessary in order to decouple UI composition from individual templates. Templates can focus on what to render, while placement determine what to render where. In yesterday’s post, I’ve shown one rudimentary example of placement. There can be a placement file at the root of each module and theme. A placement file can either be a
placement.jsonfile, or a
placement.jsfile if the format for JSON placement files is not sufficiently flexible for the problem at hand.
Placement works in a relative manner: more than one content item can appear on any given page, for example through lists of content items, or as widgets. Placement can dispatch the shapes created by the parts of a content item into the local zones under a given root shape that is usually the main shape for the content item.
A content part is a reusable piece of content that can be composed with other parts into a content type. For example, a blog post content type could be built by composing a title part, a text part for the post's body, a tags part, and a list of comments. DecentCMS comes with a few parts built-in, such as title and text, but it's easy to write your own.
Creating your own content type can be done by adding it to the configuration of the "content" feature in the site's
settings.jsonfile. You may also alter an existing content type and add new parts to it.
In this post, I'll use the example of a rudimentary tags part. The part will expose a list of tags, which are simple strings.
In previous posts, I’ve shown the structure of a DecentCMS module, and how to describe such a module through its manifest. In this post, I’ll go into the meat of the matter by showing how to write an actual service. DecentCMS services are just classes that fulfill a specific named contract. Services can consume other services, using existing or new contracts, thus providing a generic mechanism for extensibility, where extensions to core services can expose their own extensibility points.
In the previous post, I showed the basic structure of a DecentCMS module. In this post, I’ll start digging into the details by showing how a module can declare metadata about itself. The
package.jsonfile, also called "module manifest", is where DecentCMS module authors can declare what their module consists of. It is a standard NPM manifest file, with a few additional properties that DecentCMS understands.
Modules are made of all the files under a subdirectory of the
/modulesdirectory. A module may be put directly under the
/modulesdirectory, or it can be part of a "module area".
Module areas are groups of modules that have a common origin, and make sense being together. An example of a module area is the "core" area, that groups all the core modules that come standard with DecentCMS. They provide essential features that are likely to be useful to any DecentCMS web site. Another advantage of module areas is that they make it easier to manage a whole group of modules under a single Git repository.
Module areas are simply subdirectories of the
/modulesdirectory that do not have a
package.jsonfile directly under it, but has one or more modules under it. You may not put areas under areas.
The navigation files that can be found in a site's "navigation" directory describe the menus that are available to the system. The
default.jsonfile in particular describes the default menu for the site. By editing this file, you can modify the menu's hierarchical structure and its contents.
See if you can figure that one out in less than ten seconds, in which case kudos to you… What does this code return?
After an IE6-induced era of stagnation, the Web has adopted a steady pace of serious innovation and progress these last few years. Regular browser updates, collaboration on open standards, and some polyfill libraries make the Web a much more viable development platform than it used to be. Or does it? An exploration of the caniuse.com site paints a more depressing picture: Internet Explorer 8 is dragging us all behind with its market share of up to 20% (depending where you get your statistics). 20%! Are you going to leave 20% of your users behind? Should you still care that much? I’ll be arguing in this post that you shouldn’t, in many situations.
DecentCMS is relying heavily on dependency injection: it is basically a composition engine, that orchestrates services. Those services have to use one another, and dependency injection is arguably the best pattern to achieve that. Let’s go over what dependency injection does, and how it’s implemented in DecentCMS.
A content item in DecentCMS is an aggregate of parts, as defined by the content type of the item. For example, an item of type “page” is the combination of a title part, and a body part. This definition of which parts constitute a given type is configuration data that is defined at the level of the site.
Currently, DecentCMS stores content items in the file system, which is just fine for small sites, and makes editing and deploying them quite easy, even though there is no admin dashboard yet. Creating a content item is done by simply creating a file in one of the supported formats: JSON, YAML, and Snippable YAML + Markdown.
Philip asked an interesting question on the DecentCMS forums: “are there plans to allow for theme settings”? That is a great question, and I’m happy to report that the system already allows for it, that I was able to verify that it works, and that it was ridiculously easy.
It seemed like a good idea at the time: wingdings for the web, collections of vector glyphs that are easy to include in your pages. Except that a web page is not a Word document. Now that SVG is properly supported by all half-decent browsers (you don’t have to support browsers and OS’s that Microsoft won’t, do you?), why are we still using icon fonts? Let’s recap.