This page describes how requests are handled in bxcms,
what cms components are used in this flow, and what actions they perform.

First of all, request is passed to popoon sitemap.
There are 3 pipelines in main sitemap:

• First 2 are for admin stuff, they match '/admin/' and '/themes/admin/' uris.
• Last one match any other uris, used to retrieve content.

main pipeline

bxcms action

This action investigates requested uri and collection and performs some stuff:

• mangles uri to append index.html, or '/' at the end, checks mobile requests.
• handles collection (and some other) redirects
• generates pagenotfound or collection not found exceptions
• (in some cases) handles POST requests
• and most important: sets up pipeline parameters, provided in collection configxml, or configured plugins. standard parameters are:
  • 'collectionUri'
  • 'requestUri'
  • 'collection', 'filename', 'extension' (request parts)
  • 'mode' (here seems to be always 'output', it is 'admin' in admin pipelines)
  • 'lang' (determined from global config or from uri)
  • 'locale' (from global config)
  • 'webrootLang' (webroot appended with language suffix)
  • 'fileNumber' (for the gallery I think and maybe more?)
  • (collection/plugin-provided) 'xslt' (name of stylesheet from theme - required)
  • (collection/plugin-provided)'pipelineName' (defaults to "standard")
  • some plugin-specific

If bxcms action succeeded (not redirected or generated exeption),
the rest of pipeline come in play.
In default sitemap, there are 3 branches:

• "resourceReader", used just to read files w/out any processing
• "fo", used to generate pdf output from xhtml output
• default branch, used to generate xhtml output

default branch

The default branch generates main page representation.
It contains of 2 parts: generation and transform of content performed by
cocoon components bxcms-generator, bxcmsfilter-transformer

bxcms-generator

This generator creates instance of collection, related to requested collection.
It just call collection::getContentByRequest($filename,$extension)
to create DOM.
If the collection has property 'relink', then redirection occurs.
/* what is difference with redirection in bxcms action ? */

Collection::getContentByRequest method maps request into plugins that are configured and able to handle this request. This is performed taking all plugins configured in .configxml and checking if this plugins generate some id for request.

All selected plugin (pluginmap) then requested with bx_plugin::getContentById($uri,$id).
Retrieved xml is then put into /bx/plugin[@name='$pluginname'] nodes of
resulting content document, which is returned into pipeline.

preHTML bxcmsfilter

Some filters, configured in .configxml, applied to generated content,
before this content get styled by theme.
Such filters should have preHRML method to be applied here.

theme stylesheet

Dom document is then transformed using template, specified by pipeline parameter 'xslt'
(usually given in collection xmlconfig and set up in bxcms action)

postHTML bxcmsfilter

After document is converted to page layout, it is again transformed with
filters, that has postHTML method.

i18n

Next goes i18n transformer, that replaces all occurencies of elements
and attributes in namespace i18n to apropriate values, represented in
locale, specified by parameter 'locale'.
This is native popoon transformer working similar way as cocoon i18n transformer.
In bxcms it is set up to use BX_BASEDIR/master catalog.

serializetion

Finally, resulting DOM is printed out as xml, xhtml or text/plain,
according to pipeline parameter 'output-mime'.
Note, that this parameter isonly set in plugin (and determined from requested resource),
and has no relation with requested filename extension or whatever.

admin pipelines

When request is started with '/admin' (usually happen from admin-pages),
then another sitemap is mounted to handle request.

This sitemap handles:

• some webdav requests
• navigation stuff
• requests generated from editors

Some pipelines are wrapped in actions [bxcmsauth] and bxcmsadmin.
This action is similar to bxcms action.
It tries to get collection instance for mode='admin',
passes POST requests to plugins,
and sets up pipeline parameters:

• 'collectionUri'
• 'collection'
• 'id' is NOT id returned by plugins, but is always either "/$filename.$ext" or "/$filename"
• 'collectionUriOfId' collectionuri returned for such id
• 'dataUri' location of some data, as returned by collection::getContentUriById
• 'lang','locale' as set up in global config for admin pages
• 'returnPostCode' a code returned by (last) plugin handled POST request

webdav stuff

navigation stuff

There are 2 pipelines for navigation.
One is for navigation tree, and another for popup menues, requested from
javascript.

popup menues

This pipeline handles requests 'navi/popup/$path_to_resource'
and uses adminpopup reader to create <adminpopup> document, containing popup menu:

• menu of basic operations
• menu of resource types allowed to create in the collection
• menu of available editors
  Such requests are handled in admin javascripts.

Menu of operations

This menu contains 'Copy', 'Move' and 'Delete' commands
It is created if permission object allows.

Menu of resources

Resource types are created using collection::getPluginResourceTypes().
Collection find outs all plugins configured in .configxml, in section <plugins>
(unless plugins[@inGetChildren ='false']).
Then it calls plugin::getResourceTypes() for each plugin.

Menu of editors

List of editors is retrieved using collection::getEditorsById($resource_filename)
(here $resource_filename is file name, e.g. index.ru.xml - as it
requested from admin page)

Collection finds admin plugin (configured in .configxml), which returns
plugin::adminResourceExists($uri,$filename,$ext) = true
(here $filename and $ext are of resource filename)

The admin plugin is then asked for list of editors with
plugin::getEditorsById($uri,$resource_filename)

It is supposed, that there is only one admin plugin in collection.

There's also an item for property editor, if permission object allows.

navi tree

This pipeline handles requests 'navi/tree/$path_to_resource'
and uses admintree generator to create <navitree> document.

The generator requests collection::getChildren($resource_filename) to
list collection children (each is bx_resource).
This method lists all nested collections (of the same mimetype, by
default it is "httpd/unix-directory"), and also asks each configured
plugin for plugin::getChildren($collection,$id) to list all resources handled by plugin
in given collection.

For each children resource there created an item node, with various attributes:

• mimetype = resource output-mime property
• uri = resource->getLocalName()
• title = resource->getDisplayName()
• action = ref to admin page for this resource: /admin/overview/$resource_path/$resource_name, where resourcename is res->getLocalName() or res->getBaseName() for directories
• icon and openIcon = ref to icons: /admin/webinc/img/icons/ + $mimetype.gif OR fileicon_folder.gif
• iconAction

editors requests

The bxe and fck request their stuff with uris '/bxe/' and '/fck/',
such requests are routed to separate sitemaps.
Other editors may specify pipeline parameter 'pipelineName' to sepect
sitamap branch.

'standard' branch

Renders content using $resource_filename, transforming it with 'xslt'
stylesheet, i18n, and outputting as xhtml.

'xml' branch

Copies all content of /bx/plugin nodes

other branches

All other requests routed into sitemap, selected with parameter
'pipelineName' used as sitemap filename, usually it is editor name.
These sitemaps contains pipelines specific for each editor.