Website architecture patterns

This document provides direction when implementing a non-Pageseeder interface to deliver PSML content or PageSeeder functionality. 

Background

There are many use cases where it is preferable for some users to interact with PageSeeder content or processing capabilities via a more specialized interface. Examples include:

  • where a simple interface can improve productivity, reduce training, improve quality or lower risk,
  • when the permission model for viewing content is not the same as the model required for editing,
    • for example, a subject matter expert writing training material to support both teachers and students. 
  • to allow parts of the system to be specialized or isolated without customizing the native interface.

When this happens, the Berlioz developer framework provides a straightforward mechanism for extending PageSeeder using infrastructure and technologies that will be familiar to many developers.

Overview

Websites architectures based on PageSeeder and Berlioz can be prioritized for characteristics such as the following:

  • simplicity of setup (direct connection)
  • better performance, rich semantic index/search, faceted browsing, multi-level editorial process (publish model)
  • horizontal scalability, distributed content and security (REST API)

Issues that require consideration are:

  • Security model
    • users
    • content
  • File system
    • URL model
  • Content lifecycle
    • editorial workflow
    • revisions / versions
    • user interactions
    • dependencies
    • data loading
  • Search
    • semantic richness
  • User interface
    • personalization
    • messaging
    • user generated content
    • delivery paltforms
  • Developer interface
    • access
  • Admin interface
    • logging

 

Created on , last edited on