The flow of control through the pipelines is difficult to
determine given the number of sitemap files and pipelines within
these files. I've documented the flow of control for a single
scenario for the "default" publication. The flow of control
were determined by setting the logging level to
DEBUG for the sitemap category in the
lenya/WEB-INF/logkit.xconf and examining the
subsequent output in
lenya/WEB-INF/logs/sitemap.log.
This use case begins with the user at the publication's overview document. The user then selects the live view (also known as the reader's view). We'll start from there.
The sequence diagram is quite complicated even for this simple use case. There are 18 distinct pipeline matchers used, some multiple time. I provide both a sequence diagram and prose to document.
There are some interesting choices to make when documenting a Cocoon pipeline design using standard UML notation. What is considered an object and another a message is not obvious since the pipeline components do not map directly to the UML object model. This the mapping I've used in this document.
The pipeline matchers are considered to be objects in the sequence diagram. Since the matchers do not have explicit identities assigned to them, I've used the convention of the name of the sitemap file they are in and the line number. This is clearly less than ideal since the identity label will change as the sitemap file is edited.
Could we add the "id" attribute to sitemap
components as a more robust notion of identity? There would
be many other benefits other than for documentation. There
doesn't seem to be a scheme for Cocoon sitemap instances so
its unclear to me how difficult it would be to do this.
lenya/sitemap.xmap:265:31
Matcher: Wildcard: **
Simply mounts lenya/global-sitemap.xmap.
lenya/global-sitemap.xmap:840:35
Matcher: Wildcard: */*/**
This invokes the action
sitemap.action.resource-exists-enhanced
with result that file does not exist. The rest of the
action is skipped and continues with the next matcher.
lenya/global-sitemap.xmap:869:33
Matcher: Wildcard: */**
Simple mounts the publication specific sitemap.
lenya/lenya/pubs/default/sitemap.xmap:19:31
Matcher: Wildcard: **
Simply mounts the
lenya/lenya/pubs/default/publication-sitemap.xmap
This sitemap doesn't seem to serve any real purpose since it only has a single pipeline that simply mounts this one file.
lenya/lenya/pubs/default/publication-sitemap.xmap:106:36
Matcher: Wildcard: **.html
This is the main entry point into the publication. It invokes an action that does some error checking about available languages. This succeeds and it invokes a generator using the cocoon protocol (local) in the subsequence 1.2.1.1.2. It then will transform the result, again using the cocoon protocol (global) in the subsequence 1.2.1.1.3
I don't understand how the URI is change to what is see by the next matcher. Somehow the action is setting this.
lenya/sitemap.xmap:259:31
Matcher: Wildcard: **
This is the first step in implementing the
action in this chain. This is an
internal-only pipeline (which must be why it
wasn't matched in the first step). It
simply mounts
global-sitemap.xmap.
lenya/global-sitemap.xmap:741:51
Matcher: Wildcard: uri-parameter/*/*/*/**
Mounts
lenya/pubs/{1}/parameter-{2}.xmap
which in this scenario is
lenya/pubs/default/parameter-doctype.xmap.
lenya/lenya/pubs/default/parameter-doctype.xmap:30:38
Matcher: Wildcard: */**.html
This file contains only two pipelines: one for HTML files and one for XML. This is the HTML pipeline. It uses an action to determine the type of the document that is being processed. It determines it is a XHTML by, I believe, looking for the namespace attribute in root element of the document. I believe it then uses this in the URI but I'm not sure how.
I believe this completes the action portion of the matcher in the subsequence 1.2.1.1. The pipeline then continues with the subsequence 1.2.1.1.2 which is a generator component using the cocoon protocol.
lenya/lenya/pubs/default/publication-sitemap.xmap:79:49
Matcher: Wildcard: lenyabody-*/*/*/*/**
This is the pipeline that builds the
page. It aggregates all the navigational
elements (breadcrumb,
tabs,
and menu) with
the actual content of the
document all within the root element
cmsbody. It then transforms
using the stylesheet
xslt/page2xhtml.xsl. Lastly,
it serializes the document as XML.
lenya/sitemap.xmap:259:31
Matcher: **
This is the same internal-only
pipeline we saw earlier. It simply
mounts the
global-sitemap.xmap. We
are now processing the navigation
portion of the final document.
lenya/global-sitemap.xmap:736:42
Matcher: navigation/**
Simply mounts
lenya/navigation.xmap.
lenya/lenya/navigation.xmap:99:39
Matcher: Wildcard: */*/*/**.xml
Invokes a generator using the local cocoon protocol. Then calls a local resource for a fallback transformation.
lenya/lenya/navigation.xmap:65:46
Matcher: Wildcard: */*/sitetree/**.xml
Generates the XML stream
using the publication's
sitetree.xml
file, then uses the default
stylesheet
lenya/lenya/xslt/navigation/sitetree2nav.xsl
to transform the stream.
lenya/sitemap.xmap:259:31
Matcher: **
We are now in the same pipeline chain as for the breadcrumb except now for tabs.
lenya/global-sitemap.xmap:736:42
Matcher: navigation/**
Simply mounts
lenya/navigation.xmap.
lenya/lenya/navigation.xmap:99:39
Matcher: Wildcard: */*/*/**.xml
Invokes a generator using the local cocoon protocol. Then calls a local resource for a fallback transformation.
lenya/lenya/navigation.xmap:65:46
Matcher: Wildcard: */*/sitetree/**.xml
Generates the XML stream
using the publication's
sitetree.xml
file, then uses the default
stylesheet
lenya/lenya/xslt/navigation/sitetree2nav.xsl
to transform the stream.
lenya/sitemap.xmap:259:31
Matcher: **
We are now in the same pipeline chain as for the breadcrumb except now for menu.
lenya/global-sitemap.xmap:736:42
Matcher: navigation/**
Simply mounts
lenya/navigation.xmap.
lenya/lenya/navigation.xmap:99:39
Matcher: Wildcard: */*/*/**.xml
Invokes a generator using the local cocoon protocol. Then calls a local resource for a fallback transformation.
lenya/lenya/navigation.xmap:65:46
Matcher: Wildcard: */*/sitetree/**.xml
Generates the XML stream
using the publication's
sitetree.xml
file, then uses the default
stylesheet
lenya/lenya/xslt/navigation/sitetree2nav.xsl
to transform the stream.
lenya/lenya/pubs/default/publication-sitemap.xmap:50:56
Matcher: Wildcard: lenya-document-*/*/*/**.xml
This is the last part of the aggregation
in parent
subsequence. We are now processing
the document content. All this
subsequence does is mount the
doctypes.xmap sitemap file.
lenya/lenya/pubs/default/doctypes.xmap:21:39
Matcher: Wildcard: */*/**.xml
This has a nested matcher that fails. So processing simply moves to the next matcher.
lenya/lenya/pubs/default/doctypes.xmap:32:41
Matcher: Wildcard: */*/*/**.xml
This takes the document content and
transforms it using the
xslt/xhtml2xhtml.xls
stylesheet. It is finally
serialized as XML.
lenya/sitemap.xmap:259:31
Matcher: Wildcard: **
This is the implementation of the
transformation in the main entry point
into the publication which used the
cocoon protocol (global). This is the same matcher
we've seen many time now which simply mounts
global-sitemap.xmap.
For some reason this sequence is repeated twice in the log file. I have no idea why. Could it be an issue with caching?
lenya/global-sitemap.xmap:681:46
Matcher: lenya-page/*/*/**
This uses a generator using the cocoon protocol to a local pipeline. It then invokes a series of actions and transformers involving i18n and menu creation.
I don't believe this subsequence has any effect on the document.
lenya/global-sitemap.xmap:731:63
Matcher: menu-xml/*/**
This is a internal-only matcher that
simply mounts the publication
specific
lenya/pubs/default/menus.xmap.
lenya/lenya/pubs/default/menus.xmap:17:36
Matcher: live/**
This file only has a single
pipeline with two matchers, the
first which is matched here. Is
uses the XSP
lenya/lenya/content/menus/live.xsp
which seems to set some meta
imformation.
I don't understand what the purpose of this matcher is.