URI Scheme
Introduction
We want to standardize CMS functionality across different publications so that we can consolidate them in a standard root sitemap.
In order to achieve this one precondition is to standardize on the URIs how the CMS functionality is invoked.
There are different ways to achieve this. We either reserve part of the URI space (e.g. /lenya/foo) or we reserve part of the request parameter space (e.g. /foo?lenya=bar)
Dynamic URIs
We decided to go mostly for the second solution so that we can leave the URI space as required by the publication and use request parameters to invoke CMS actions.
We define two standard request parameters which we use to invoke all CMS actions in a standard way:
-
lenya.usecase
- The name of the use case, e.g. "publish"
-
lenya.step
- Each use case can have multiple steps, e.g. "showscreen"
For further information about usecases, see section Usecases.
Static URIs
There are also some static URIs that are needed for the Lenya CMS. They are mostly internal pipelines for resources such as the menu, css or support files for Xopus and Bitflux editors.
There is currently no consistent standard as to under which
URI space these resources should be located. Some are
residing in /xopus/**
or
/bitflux/**
and others are in
/lenya/**
.
URI definition
Given the URI
/lenya/computerworld/authoring/news/foo.html
we
define the following parts:
URI fragment | Name |
---|---|
lenya |
context-prefix
|
computerworld |
publication-id
|
authoring |
area
|
news/foo |
document-id
|
Static URIs
Currently different fragments of the URI space are reserved
(e.g. /xopus/**
, /bitflux/**
and
everything under /lenya/**
that hasn't been
defined previously).
The reserved URI space needs to be consolidated and standardized.
Dynamic URIs
The dynamic URIs that are used for usecases are explained in the section Usecases.