Differences between revisions 11 and 12
Revision 11 as of 2007-07-30 13:50:08
Size: 6301
Comment:
Revision 12 as of 2009-09-20 23:27:48
Size: 6305
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 88: Line 88:
This will call the uriparametrizer action (see [http://localhost:8080/lenya/docs-new/docs/components/URIParametrizer.html]) This will call the uriparametrizer action (see [[http://localhost:8080/lenya/docs-new/docs/components/URIParametrizer.html]])
Line 117: Line 117:
 The items in the page-envelope: namespace are defined in the pageEnvelope module (see [http://localhost:8080/lenya/docs-new/docs/components/pageenvelopemodule.html])  The items in the page-envelope: namespace are defined in the pageEnvelope module (see [[http://localhost:8080/lenya/docs-new/docs/components/pageenvelopemodule.html]])
  • The sitemap details given below may not be up-to-date, but the general concept still applies.

This is a draft of a walkthrough of how Lenya generates a page in response to a request. To do this I turned on the debug level of logging by changing the value of logging from ERROR to DEBUG in WEB-INF/logkit.xconf and tailed WEB-INF/logs/sitemap.log, grepping for 'DEBUG'.

I'm writing this up as much to learn Lenya as well as document it, so I welcome your comments, amplifications, and corrections.

This page assumes you've installed Lenya from a nightly build.

A Walk Through the Publishing Process

Goto http://localhost:8080/lenya/default/authoring/index.html. You'll be directed to the login page. Login with lenya/levi.

Tailing the sitemap.log:

"Matcher 'wildcard' matched prepared pattern '*/**' at webapps/lenya/sitemap.xmap:760:33"

Which is:

{{{<!-- Resources --> <map:match pattern="*/**">

  • <map:act type="resource-exists">

    • <map:parameter name="url" value="lenya/pubs/{1}/resources/{2}"/> <map:mount uri-prefix="" src="lenya/resources.xmap" check-reload="true" reload-method="synchron"/>

    </map:act>

</map:match> }}}

No matches here so we continue through the main sitemap.

The next hit is:

"Matcher 'wildcard' matched prepared pattern '*/**' at webapps/lenya/sitemap.xmap:768:33"

{{{<!-- Enter the actual publication --> <map:match pattern="*/**">

  • <map:mount uri-prefix="{1}" src="lenya/pubs/{1}/sitemap.xmap" check-reload="true" reload-method="synchron"/>

</map:match>}}}

Defining:

  • /0 default/live/index.html
  • /1 default
  • /2 live/index.html

This match brings the publication specific sitemap for the 'default' publication, webapps/lenya/lenya/pubs/default/sitemap.xmap, into scope.

Now we see:

"Matcher 'wildcard' matched prepared pattern '**' at webapps/lenya/lenya/default/sitemap.xmap:56:31" {{{<map:match pattern="**">

  • <map:act type="authorizer"> <map:match pattern="login-screen">

    • <map:call resource="login"/>

    • </map:match>}}}

;Note;I'm going to punt on the ACL piece of this for the moment.

After the ACL checks

It appears that we're back in the scope of the default publication sitemap as the next event is "Matcher 'wildcard' matched prepared pattern '**' at webapp/lenya/lenya/default/sitemap.xmap:93:35" {{{<map:match pattern="**">

  • <map:mount uri-prefix="" src="publication-sitemap.xmap"/>

</map:match>}}}

And we're now in the domain of publication-sitemap.xmap.

"Matcher 'wildcard' matched 'wildcard' matched prepared pattern '**.html' at webapps/lenya/lenya/pubs/default/publication-sitemap.xmap:104:36"

{{{<map:match pattern="**.html">

  • <map:act type="uriparametrizer" src="{1}.html">

    • <map:parameter name="doctype"

      • value="cocoon://uri-parameter/{page-envelope:publication-id}/doctype"/>

      <map:parameter name="document-id"

      • value="cocoon://uri-parameter/{page-envelope:publication-id}/document-id"/>

      <map:aggregate element="lenya" label="aggregation">

      • <map:part src="cocoon:/lenyamenubar/{page-envelope:area}/article.xml"/> <map:part

        • src="cocoon:/lenyabody/{page-envelope:publication-id}/{page-envelope:area}/{doctype}/{document-id}"/>

      </map:aggregate> <map:transform src="xslt/{doctype}-{page-envelope:area}.xsl"/>

    </map:act> <map:serialize type="html"/>

</map:match>}}}

This will call the uriparametrizer action (see http://localhost:8080/lenya/docs-new/docs/components/URIParametrizer.html)

This process is studying the request URI and generating a collection of parameters from the URI.

The first is the doctype.

The action calls back out to the main lenya sitemap for

cocoon://uri-parameter/default/doctype/live/index.html

which is intercepted by webapps/lenya/sitemap.xmap:665:51

{{{<!-- uri-parameter/{publication-id}/{parameter}/{area}/{uri} --> <map:match pattern="uri-parameter/*/*/*/**">

  • <map:mount uri-prefix="uri-parameter/{1}/{2}/"

    • src="lenya/pubs/{1}/parameter-{2}.xmap"

      check-reload="true" reload-method="synchron"/>

</map:match>}}}

This mounts the parameter-doctype.xmap which executes an XSP page to generate the parameter value.

This is done for both the doctype and document-id parameters.

;Question;since doctype and document-id are availble from the pageenvelope namespace, why do we generate them here?

These are used in the following aggregation step.

The aggregation constructs the menubar using an XSP page:

{{{<map:match pattern="lenyamenubar/live/article.xml">

  • <map:generate type="serverpages" src="../../content/menus/live.xsp"/> <map:serialize type="xml"/>

  • </map:match>}}}

And calls a named pipeline, lenyabody, to generate the rest of the page components.

{{{<!-- This is the pipeline that builds the page. It aggregates all the navigational elements (breadcrumb, tabs, menu) with the actual content of the document. --> <map:pipeline> <!-- /lenyabody/{publication-id}/{area}/{doctype}/{document-id} -->

  • <map:match pattern="lenyabody/*/*/*/**">

    • <map:aggregate element="cmsbody"> <!-- <map:aggregate element="body"

      <map:part src="cocoon://navigation/{1}/{2}/breadcrumb/{4}.xml"/> <map:part src="cocoon://navigation/{1}/{2}/tabs/{4}.xml"/> <map:part src="cocoon://navigation/{1}/{2}/menu/{4}.xml"/> <map:part src="cocoon://{1}/{2}/{3}/{4}.xml"/>

    • </map:aggregate> <map:transform src="xslt/page2xhtml.xsl">

      • <map:parameter name="root" value="{page-envelope:context-prefix}/{1}"/>

      • </map:transform> <map:serialize type="xml"/>

    </map:match>

</map:pipeline>}}}

As the final step, we call the html serializer and we're done.


13 June 2003: Cleaned up the Sitemap extracts to keep the page from sprawling. BillHumphries

SitemapWalkthrough (last edited 2009-09-20 23:27:48 by localhost)