What are 'Index Widgets'?
Widget Sub Page Templates
Index Widgets are just like normal Widgets. However, they configure one or more Widget Sub Page Templates, referred to in the configuration as 'inner_templates'.
This lets admins working in the CMS create new pages using a new Widget Sub Page Template.
The Design Mode theme comes with some Index Widgets ready to use. These are the Blog and the Forum widgets.
A typical widget JSON configuration might look like this:
{
"widget_info":{
"title":"Carousel Slide"
,"title_info":"Enter a name for this instance of the widget. This is just used for reference."
,"category":"text"
},
"meta_data":[{
"name":"Autoscroll speed"
,"type": "text"
,"info":"Enter a number in seconds for the autoscroll speed. You only need to configure the on the first of a set of consecutive widegets. Use 0 for no autoscrolling."
,"var": "speed"
,"default":"3"
},{
"name":"Number of items"
,"type": "text"
,"info":"Enter a number of items to show per slide. You only need to configure this on the first of a set of consecutive widgets."
,"var": "items"
,"default":"1"
}],
"inner_templates":{}
}Notice how the inner_templates object is empty. To convert the widget into a widget that exposes new inner page templates in the CMS, we'd define at least one item in the inner templates object like this example taken from the Blog template included with the Design Mode theme:
"inner_templates":{
"bloginner": {
"name":"Blog article",
"template_sections":[
["","Article content","1"],
["Poster_Image","Preview Image","0"],
["Sidebar_Content","Sidebar content","0"]
],
"meta_data":[
{
"name":"Author"
,"info":"Enter a name for the author of this blog article."
,"type":"text"
,"var":"author"
},{
"name":"Published date"
,"info":"Enter the date that this article should show. More recent dates will bring posts to the top of the page. Ensure the date is in this format: YYYY-MM-DD HH:MM"
,"type":"date"
,"var":"date"
}
,{
"name":"Belongs to blog"
,"type":"tagchooser"
,"onlyshow":"tagids"
}
,{
"name":"Categories"
,"type":"tagchooser"
,"onlyshow":"publiccats"
}
,{
"name":"Tags"
,"type":"tagchooser_withquickadd"
,"onlyshow":"publictags"
}
],
"child_data":{
"blogcomment":{
"approved":{"type":"tick","label":"Approved"},
"name":{"type":"text","label":"Name"},
"email":{"type":"text","label":"Email"},
"website":{"type":"text","label":"Website"},
"message":{"type":"text","label":"Comment"}
}
}
}
}
Here we can see we've created a new inner page template with the id of 'bloginner' and visible name of 'Blog article'. Notice also how we've set up three template sections. These are the template sections that the CMS admin will see when they edit a page created with one of these templates. As soon as this inner template is defined and saved in the widget file, it exposes the new template in the Website pages insert palette.
How do inner templates work?
A good way of thinking about how inner templates work is as follows.
Each template layer app will have an index page defined by the page where the widget itself is added. For example, if you made a new normal page called Blog, then added the Blog widget to that page. That page would then be the index page for that instance of the widget/template layer app.
Then, if someone created a new page with the 'Blog article' template, and they called it 'My new article', that would show up as an item when viewing the Blog page. Clicking would then show the actual article as a sub page using this URL: /blog/my-new-article/
The widget template will then be used to display that article within the area occupied by the main Blog widget and use the outer template of the Blog index page for the page styling.
API Functions and Modifiers
As SetSeed has evolved, the templates that are used to control the outer design of the webpages it creates have become more powerful through the addition of automated functions and modifiers.
We now have a full library of API functions that can be used within templates that interact with the core functionality of the CMS. There are several different data storage models that you can interact with. These are listed below.
This means you can now build complete 'apps' within the templates as they can be configured natively within the CMS by the content editors. Because everything works through an API there's no risk of breaking the core application and the interface the content editor uses to configure these template layer apps is all consistent with the rest of the system.
Pages
Access and create webpages. Either normal pages or template 'inner' pages. These pages will show up in the CMS for moderation or editing by site owners. Pages can be located using their URL or their ID.
Page meta data
Pages can have meta data stored with them. This can be optionally editable in the CMS or it can be hidden for use only by the template. Data is stored simply as a series of key value pairs.
Page child data
Each page can have child data associated with it. Child data is a series of defined objects that can be repeatedly added and iterated over in the templates. Comments on a blog article are a good example of this data storage model. The properties of each different type of page child data are configured in the json configuration block at the top of a template layer app file. New page child data can also optionally be shown in the CMS Activity feed.
User meta data
Users can have their meta data added to or edited. These are visible in the CMS to site owners and values are also included in CSV exports from the system to. This can be used to create systems that let users edit their own preferences or other values.
User child data
Like page child data, user child data is a collection of data objects with defined sets of properties that belong to a user. Things like custom form submission could be stored using this format. The output can also be optionally shown in the CMS Activity feed.
Emails
You can also access emails created in Compose, and queue up emails to send immediately or later, all directly from the templates.