CirclesCMS (or just Circles) is an easy to use and easy to program, single page html5 content management system and blog engine built around websockets and angularjs.
It accomodates some ideas of various projects like Wheat or Sling.
The following is a short list of high-lights of Circles:
Some ideas coming soon:
Circles is built to make single page websites possible. That means, after the initial load, the user does not need to reload the page or leaves the page when clicking on a link. Modern web pages make this possible with the use of Ajax or even more modern web pages with the use of websockets. CirclesCMS uses the latter approach.
To achieve this behaviour of not reloading a page on a click, the html5 history API is used. Circles listens on changes of the url therefore and makes an rpc call to the socketserver. Based on the url a resource on the server is resolved and based on the resource returned from the server the client resolves a template.
Circles uses this approach to answer 3 Questions arriving in a CMS: What? How? Where?
A resource is basically either a directory or a file in a repository. By default, two types of resources are known: list and item
A directory will always be a resource of type list. A file will by default be a resource of type item, which can be overridden with the use of metatags.
Currently only two types of files are supported:
HTML parsing is not supported at the moment, which means HTML-files will be delivered as is with the type set to the default type item.
The library metamd supports the usage of metatags in markdown files, which means the resource type can be overriden, by defining the metatag type.
A resource will be tried to resolve in the following order:
To give you an idea I give some examples:
/a -> no suffix, trying default suffixes
/a.html ->
/a.md ->
/blog/a ->
Templates reside on the client side. The use the angular notation. They will have the suffix .html.
After retrieving the response from the server the client decides based on the same principle which template to use for rendering.
A template will be chosen based on the type and the path.
Some examples:
/a -> found content a.md, no type given, default type item
/a -> found content a.html, no metadata or type support, type none
/blog/a -> found content blog/a.md, type article
/blog -> found content blog/, directory, type list
/doesnotexist -> no resource found, error returned
/blog/doesnotexist -> no resource found, error returned
At the moment all resources are rendered in the same container using the angular directive ngView.
Depending on the url following content will be retrieved assuming following content structure:
/
|- about.md
|- contact.md
|- blog/
|- afile.md
|- anotherfile.md
|- directory.md
|- directory/
| |- file1.md
| |- file2.md
|
|- tmp/| URL | Content | Result |
|---|---|---|
| /blog | Directory | A json list containing the non recursive content of the Directory blog (see json). |
| /about | File | The rendered content of the file about.md. |
| /blog/afile | File | The rendered content of the file blog/afile.md. |
| /doesnotexist | Error | An error message formated as json. |
| /blog/directory | File | The rendered content of the file blog/directory.md. |
As you can see, an Item has precedence over a List. Thus I encourage to use unique paths, because in the case of /blog/directory you are not able to retrieve the directory listing. That means you can for example link to the files in /blog/directory manually in the file directory.md.
The json of an item contains all metatags. So a get on /blog, assuming blog is a directory, will return following object:
{
"res": [
{
"title": "A title",
"date": "2013-01-01",
"author": "Christian Sterzl",
//
// other metatags
//
"path": "blog/afile",
"type": "item"
},
{
"title": "Another title",
"date": "2013-02-02",
"author": "Christian Sterzl",
//
// other metatags
//
"path": "blog/anotherfile",
"type": "item"
},
{
"title": "Another title",
"date": "2013-02-02",
"author": "Christian Sterzl",
//
// other metatags
//
"path": "blog/directory",
"type": "item"
},
{
"path": "blog/tmp",
"type": "list"
}
]
}A GET-request on /blog/directory resolves to blog/directory.md and will return following resource:
{
"title": "Another title",
"date": "2013-02-02",
"author": "Christian Sterzl",
//
// other metatags
//
"path": "blog/directory",
"type": "item",
"body": "<h1>Escaped Body Content</h1>"
}An error message in json format will look like following:
{
"type": "error",
"code": "404",
"message": "Content Not Found"
}