Dependency management - on demand publishing or pre-generated content?
Editorial objects have dependencies, since they refer to each other. Just think about simple hyperlinking. The link caption often contains the title of the target text. What if this title changes? Then we need to update the link caption also.
In our CMS we have documents about products (which obviously mention the name of the producer) and also a document about each producer.
When the company rebrands (changes name from Company1 to Company2) we need to update the content of all product document the company is mentioned. I’m not talking about updating the editorial content, but the published content.
Depends on the
- content / data complexity
- quality assurance workflow
- content / data distribution
… we can choose from two web publishing strategy:
- on demand
- pre-generated content
On demand publishing
With this approach the web application fetches the content components directly from the XML backend (maybe from an XML database) and does page composition on the fly:
- assembles different components
- dependency resolution: injects data fetched from other documents what this document is dependent on - for example injects the name of the producer fetched from the producer object
- link population
- format conversion (XML to HTML)
- Highly flexible, pages can be formed dynamically, even controlled by user profiles.
- Relatively simple dependency management.
- It can be a time consuming process, but obviously the server can cache the composed content pages… if they’re not highly user specific.
- Quality control is challenging.
- Complex webapp backend.
Publishing based on pre-generated content
If we want to keep the webapp as simple as possible, then we need to separate page composition and page presentation. We then generate static HTML pages in a pre-process and our webapp backend will simply store these static pages.
Then page generation does not have to happen in real time, less load on the server, however the object dependency management will be more complex because then we don’t build just one page at a time, but one change can affect several pages. The figure above shows that if Company1 rebrands to Company2, then we also need to republish all product documents where the company name is mentioned.
Such semantic links shown above can help us in dependency management, but please don’t underestimate this. We can end up with a complex dependency graph and this dependency is not simply between objects. We don’t need to republish product documents if the producer document changed, but only if the producer name changed.
- Good testability.
- Simple backend can serve the webapp.
- Little flexibility regarding to the page content.
- Complex dependency management.