Feature Demo: Data Datasource

Datasources provide the backbone to consume data/remote APIs and render to an experience for visitors.

There are several types of datasources provided by the platform core. The most simple datasource is the Data datasource.

The datasource module provides this datasource to easily copy and paste a JSON array of data.

Items in a datasource can be displayed using none datasource content panes. The example provided here will use a snippet.

Snippet is created with a title token. Once wired to the datasource in the following steps when rendered the datasource will be looped through and the snippet defined here will be rendered for each item in the datasource. However, before that can be done there are a few more steps.

For a pane to be findable to bind to a datasource it must be named. Clicking on the three vertical dots to the left of the pane content type will reveal a menu with an option for props. When props is clicked a dialog will pop open allowing users to define properties for the name. Among those properties are name and title. Fill in a name and title for the panes as shown below. In theory the datasource doesn't require a title or name but it can make things easier to find when panel pages become more complex naming panes of all type something meaningful.

After naming the snippet pane the three vertical dots inside the datasource pane can be clicked to reveal a menu with an edit button. When the edit button is clicked the datasource settings can be modified. These settings include the bindings. All datasources will have an options to add bindings since that is what enables the datasource to be associated with other panes for rendering or chaining. Currently the focus is on rendering but datasouces can also be chained together to transform and massage data client-side. This will be discussed later in the document.

After saving clicking the horizontal bars in the top left corner will reveal a menu. Clicking the properties link in that menu will provide the properties for the root panel page itself. Fill out those properties as seen below. The name, and title should be fairly straight-forward. The path is the path the panel page will be accessed. The css file settings can be ignored for now but allows for a stylesheet to be added when using the verti-go/framework rest persistence instead of index db. Probably more information than is needed at this point. The read permissions allow are set to start which means everyone. In theory that doesn't really matter because the demo stores everything in a local database and doesn't persist anything to a remote database for storage beyond a user browser session.

After saving props the upper left menu can be opened again to save the panel page. For the demo editor the save will store the panel page inside index db. One important note about the save process is it should be extremely fast even when using an api. The panel page is stored in its natural form for both idb and currently implemented rest api. Saving these objects in their natural form instead of to something like a relational database provides much more flexibility and scalability benefits over traditional storage methods like MySql typically seen with older, legacy type applications. This is one of many things that makes Druid very different from traditional content publishing platforms. Druid uses modern cloud technology to facilitate scaling storage of entities like panel pages storing them in their natural form. Druid also implements a fairly low level amount of abstraction over these storages unlike other systems where there can be mountains of abstractions making the code very difficult to follow. Storages are based on an extensible crud adaptor system that will be discussed in a future doc.

Once successfully saved the panel page is ready to viewed at the path specified in the properties dialog.

Each item rendered is much more than just html content. Each item is a living breathing entity that can have further behaviors attached and also maintains state. Those topics are for another time but it's important to understand that each item is an individual component not just static content. This provides a mountain of possibilities all achieved without writing any code. Most importantly providing a pattern of combining datasources with a snippet to establish a reusable pattern for consistently presenting any type of data. All future discussions about datasources will extend on this concept of consistent, reusable data presentation methods.

Every datasource will provide its own settings to configure it and probably the most obvious next data source would be REST. The rest datasource will be discussed in a future demo. However, the current marvel browser demo makes extensive use of datasource capabilities and can reviewed in the mean time.

Marvel Character Browser Demo: https://ng-druid.github.io/dev-test-virtual-list-flex-v1/character/1011334