How JellyPot works

JellyPot is made with great love by designers and developers for designers and developers. This page explains its architecture, features and principles.

Fundamental principles

Most CMS are page-centric. They offer a range of fixed, predefined templates. However these universal templates suit only specific use cases (i.e. Wordpress templates are useful for blogs).

To solve the problem, these systems offer vast plugin eco-systems. But this only eludes the problem without actually solving its cause. In fact, this is a matter of page-centric approach. Which is even more problematic today when you may want to re-use your content in a range of media including mobile apps that have no pages at all.

When we set out to build JellyPot we did not consider mobile apps at all. Mobile apps did not even exist. It just felt natural to focus on content and not pages. We decided on following principles:

  1. Content management must be separated from CMS configuration. The content editors should not deal with an interface that lets then modify templates, configure database and generally break things.
  2. Developers must be free to choose their tools and processes. We should not force developers to use specific tools, be it a select JavaScript library, style of writing CSS or a specific markup. We should let them use tools and processes they know and like.
  3. Data must be stored in presentation-free format. Data must be stored regardless of how they will be displayed on the page. Content appearance should be created when the page is rendered, not when the content is entered in admin interface. That will also give full control over website look to developers and designers.
  4. CMS must adapt to to the content, not the other way round. Any content can be modelled, no matter how complex its is.

Content model

To break with a page-centric model, which substantialy limits the possibilities of presentation and content re-use, we based JellyPot on custom structured content model.

Custom structured data types

Elementary data types such as Text, Date or Integer can be put together to form complex content structures exactly matching your needs – for example these can represent a Book, a Product, a Testimonial, or a Recipe. Since these structures are not tied to any specific page, the content or its part can be used and re-used on any page.

Collections

Custom types can be used for creating collections that contain more items of a given type. It is possible to create collections of collections, of course ;)

Relationships

Finally, relations between collection items can be made. Otherwise the items would be isolated islands and it would be possible to model only very trivial content. In real world Books have Authors, Articles belong into Categories etc. Relations can be either 1:N or M:N.

Language support

JellyPot fully supports multilingual sites. This is not an afterthough. Multilingual support is built in at the content model level. Language versions can be easily added or removed at any moment, during development or even in production. Internally JellyPot works in UTF-8 so you can use virtually any alphabet – be it Latin or 漢字.

Images of all sizes and compressions

JellyPot can automatically modify images on upload. You can define multilple required dimensions, resizing method, cropping etc. This comes handy for responsive websites or when you need a thumbnail on one page and full resolution on the other. Compression levels can also be specified so you can serve high-res high-quality images to desktops and smaller, more compressed to mobile devices. Developers set needed resolutions and compression levels in the content model and in page templates. Editors who manage the content then simply upload a JPEG file and JellyPot does its magic.