Composr Tutorial: Choosing how to publish

Written by Chris Graham (ocProducts)

When it comes to deciding how to release information, things can be difficult with Composr. Not due to complexity, or lack of features – but because Composr offers so much to choose from, that you actually have the opportunity to sit back, and think, 'which is best for me?'.

This tutorial will summarise the main ways to release information in Composr, and the relative advantages and disadvantages of each.

There are other ways of releasing information in Composr not mentioned here, such as newsletters, and other less-obvious ways. However this tutorial focuses on published and archived forms, rather than the full range.

Table of contents

Composr Tutorial: Choosing how to publish

The ways

The main ways to release information in Composr are:

Comcode pages
News articles
Catalogues
Wiki+
Discussion forums
Downloads

Comcode pages are usually the most appropriate way of releasing permanent information, as they are standalone, and thus not cluttered with additional module-specific information and navigation mechanism, and not linked in with any complex metaphor.

News articles are great for releasing "update" information. They are permanently archived and linkable, and thus may be used for permanent information, but this will only really be desirable for uses such as journals due to the explicit dating of the material.

Catalogues store information in a database-like fashion, with a strict record format that the stored information must comply with. This is therefore very appropriate for holding records, but feels forced for holding documents.

Wiki+ is a very ad hoc system, and designed as a community database (but not in the formal sense of a database with records). It is great for storing structured information when presentation is less important than efficiency of use. Imagine Wikipedia.

Discussion forums are even more ad hoc from Wiki+, and while they can be heavily structured, they are designed to hold transitory information. Two distinct advantages are the efficiency that moderation features provide, and the fact that users tend to 'lurk' on forums and thus information released through forums reaches them fast.

Downloads may be used to release information indirectly, essentially via storing it in an archive of files/publications.

Comparison table

	Comcode pages	News articles	Catalogues	Wiki+	Discussion Forums	Downloads
User submittable	Not really	Yes	Yes	Yes	Yes	Yes
Supports validation	Yes	Yes	Yes	No	Yes	Yes
Quick to add (to)	Yes	Yes	Yes	Yes	Yes	Yes
Automatically indexed	No, except on site-map	Yes	Yes	Yes	Yes	Yes
Clean	Yes	Moderately	No	No	No	The content is not on the page: it is provided there.
Regularly browsed	No	Moderately	No	No	Yes	No
Structured data	No, unless you use Custom Comcode tags for this	No	Yes	No	Moderately (via post templates)	Any file type can be presented for download.
Transitory	No	Yes	No	No	Yes	No
Easy to reorganise	No	No (and you wouldn't!)	No	Yes	Yes, very!	No

Content type terminology

We use 4 generic words in Composr for describing content:

Content type (plural: content types)
Resource (plural: resources)
Category (plural: categories)
Entry (plural: entries)

None of these things have any specific implementation in Composr. For example, if you looked in the Composr code you wouldn't find an "entry" defined anywhere in it. They are just words we use consistently to describe how parts of the system behave and relate to each other.

A content type is just as it sounds: a type of content. This could be a download, a gallery image, a banner, or an entry within an individual catalogue. Catalogues are essentially custom content types, i.e. they allow a site to create new content types without programming.
Each content type in Composr runs from separate code, and separate database tables, in a separate addon, served from a separate module(s) – except for catalogues, which all share those things.

Resource can refer to any kind of "thing" in the system, including catalogues, categories, entries, members, usergroups, or just about anything else. We use the term quite loosely.

Entries are organised within categories.

Categories in more detail

Categories are containers for entries. Most content types have categories, although they may be given different actual names in the system.

A gallery is a kind of category. So images and videos are organised in gallery categories, aka galleries.

A banner type is a kind of category. So banners are organised in banner type categories, aka banner types.

Downloads are organised in download categories.

Sometimes categories are hierarchical, e.g. they are for galleries and download categories, but are not for banner types. By hierarchical, I mean that categories can contain more categories ("subcategories"), forming a tree structure.

Catalogues are like their own content types, and come with categories. Whether those categories are hierarchical or not is chosen as an option of the catalogue.

So…

A content type (e.g. galleries, banners, downloads, an individual catalogue) usually contains categories, which sometimes are hierarchical – and categories contain entries.

Modular CMS vs mixed content-trees

For a discussion on how our CMS approach works, see the What Composr is not page.

The narrow-in option

Normally when browsing through categories you're opening up a category and seeing what's in it. If the "Narrow-in when browsing" config option is enabled then going deeper into categories works as a filter.

E.g. if you have files X and Y categories as follows:
root > a > File X
root > a > b > File Y

Without narrow-in, you see nothing under the root, file X under 'a', and file Y under 'b'.

With narrow-in, you see everything under the root, everything under 'a', and just file Y under 'b'.

Infinite scrolling

There is an option "Infinite scrolling" if you wish to enable infinite scrolling for navigating back through old content rather than traditional pagination.

The amount of data in each 'wave' of results that loads will be based on the maximum-per-page that would apply to regular pagination.

The infinite scrolling is programmed to load more results each time you scroll down if:

It is not currently waiting for more results to load
And, you have less than 2 scrollbars of results to read (to make sure scrolling can remain relatively continuous – results may take a while to load depending on user connection speed)

It is not based on the proportion of previous 'waves' of results that the user has read. This means that if that maximum is relatively small then a lot of AJAX requests will be fired off as the user scrolls down in a machine-gun-like manner.
It's therefore not recommended to have the maximum-per-page setting too low.

Feedback

Please rate this tutorial:

Have a suggestion? Report an issue on the tracker.