Introducing the debate between CKAN Theme and PortalJS Framework for your CKAN Data Portal. As organizations worldwide harness the power of CKAN, the leading open-source data management system, the question arises: which front-end approach best suits your data portal needs? In this exploration, we delve into the nuances of CKAN themes and front-end JS frameworks like PortalJS, dissecting their advantages, disadvantages, and ideal use cases. Join us as we navigate the intricacies of CKAN front-end development to help you make informed decisions for your data portal project.
CKAN and CKAN theme
CKAN is the world’s leading open source data management system for powering data hubs and data portals.
CKAN is built on top of Flask and Flask itself leverages Jinja2 as its template engine. Jinja2 is a template engine for Python, used in Flask applications to render HTML templates. It allows Us to separate the presentation logic from the application logic, and it supports variables, control structures, and template inheritance.
A different template engine can be used, but Jinja2 must be installed to run Flask itself. This requirement is necessary to enable rich CKAN extensions. An extension can depend on Jinja2 being present. So CKAN pages are generated from Jinja2 template files, but also We can write our own custom template files to modify and replace the default ones, and change the layout, content and the styling of the CKAN pages. A CKAN theme is simply a CKAN plugin, that is a part of custom CKAN extension and contains custom templates and static files that We have written in order to overwrite the default ones and implement a change (of the layout, the content, the styling and the look) of the CKAN instance. The CKAN front-end can be fully customized by developing a CKAN theme. CKAN themes can customize all aspects of CKAN’s front-end, including changing any of CKAN’s templates or template snippets, adding custom snippets and helper functions, customizing CSS and JavaScript, and adding static files such as images.
CKAN as a back-end
For CKAN as an open-source data management system the focus is the open data itself, or to put it in other words – make it easy to publish, visualize and share the data. This can be done via the web interface or via the CKAN API that exposes all of CKAN’s core features to API clients. Everything you can do with the web interface and more, can be used by external code that calls the CKAN API. With that said, usually there are no front-end settings that require lots of customisations from the development side in order to get richer front-end data sharing experience or a lot of client-side interactivity and real-time updates.
So when do we need a “decoupled” approach where the front-end is a separate service from the back-end (the CKAN) and interacts with the back-end via an API? When the CKAN theme is just not enough and using a PortalJS framework makes sense?
- For example, if we have a content management system (like WordPress) and CKAN as the data portal platform and We want to integrate the two systems together, to avoid the complexity, after all, CKAN is written in Python and requires a PostgreSQL database, whereas WordPress is written in PHP and requires a MySQL database, a PortalJS can be used to integrate the two systems together.
- Unless our CKAN instance requires a very complex and stateful interface, many things related to UI can be rendered as templates and stitched together using “include” and “block” statements. But, in rare cases, if the instance does require a complex and stateful interface and we do have a lot of client-side interactivity and real-time updates on the web interface, we have the resources and as well staff that are comfortable using and developing PortalJS framework than we can consider some of the popular JS frameworks like NextJS as a front-end to the back-end working CKAN instance.
These are only two examples where we can consider using some JavaScript framework as front-end, probably there are some more but using a “decoupled” approach comes with a price. Below is one list of advantages and disadvantages when using a JavaScript framework as front-end.
CKAN theme vs PortalJS
| CKAN Theme | Portal JS |
| Use CKAN APIs out of the box | Additional development needed and can get complex for setting up CKAN API on front-end url |
| Use out of the box CKAN helpers in the templating files | Additional development needed and can get complex for using CKAN helpers |
| Deploy and maintain only CKAN | Extra resources used because of deployment and maintenance of both CKAN and PortalJS |
| Harvesting the data to/from the CKAN instance is a straightforward process | Can be camplex to setup data harvesters to harvest the data via the front-end framework |
| If needed, getting to work Jinja2 and React together can get complex | Easy customizable React possibilities for enhancing the front-end and the User experience |
Conclusion
So which one to choose: CKAN theme or PortalJS? Why the complexity? At the end is it style versus functionality and efficiency?
If the focus is on the open data itself, or publishing, managing and sharing it. If the full (and powerful) CKAN’s Action API is of importance for the managing and sharing that data for both the admins and editors of the CKAN instance and for all the users and services that consume that data, then maybe CKAN theme is a better choice.
On the other hand if the CKAN needs to be seamlessly integrated with some other content management systems (like WordPress) and we do have a lot of client-side interactivity and real-time updates on the web interface (not on the open data itself), and we have the team and the resources to do so (after all using a “decoupled” approach comes with a price), then some of the complexity of the integration can be avoided with implementation of a PortalJS on the front-end and we’ll have a seamless integration with the CMS. In this case a “decoupled” approach, introducing a PortalJS on the front-end can be a better way to go.
