On 1/31/06, Derek Harmel <[EMAIL PROTECTED]> wrote: > > Can you post the relevant pipelines here? > > Sure, but I think I found part of the answer to my problem. But I > still don't understand where processing ends. If it helps, my xmaps > haven't really been altered except for publication-sitemap. > > <map:pipeline> > <map:match pattern="*/*/*/*/*/jobopenings/*.html"> > <!-- This is here to test to make sure I was getting into this pipeline > <map:call resource="blah" /> > --> > <map:aggregate element="cmsbody" label="debug"> > <map:part src="http://localhost/job.php?id={6} /> > <map:part src="cocoon:/body-headers.xml"/> > </map:aggregate> > <map:transform src="xslt/page2xhtml-{4}.xsl" label="debug"> > <!-- <map:parameter name="root" > value="{page-envelope:context-prefix}/{2}/{3}"/> --> > <map:parameter name="url" value="{5}"/> > <map:parameter name="document-id" > value="/tech/careers/jobopenings"/> > <map:parameter name="document-type" value="xhtml"/> > <map:parameter name="language" value="en"/> > <map:parameter name="date" value="{date:}"/> > <map:parameter name="rendertype" value="{1}"/> > </map:transform> > <map:transform type="i18n"> > <map:parameter name="locale" value="en"/> > </map:transform> > <map:serialize type="xml"/> > </map:match> > </map:pipeline> > > Further down is: > > <map:match pattern="**.html"> > <!-- Same deal as above > <map:call resource="blah1" /> > --> > <map:act type="language-exists"> > <map:select type="resource-exists"> > <map:when test="{global:cache-dir}/{../1}.htmlDISABLED"> > <map:read src="{global:cache-dir}/{../1}.html" > mime-type="text/html; charset=utf-8"/> > </map:when> > <map:otherwise> > <map:generate > src="cocoon:/lenyabody-view/{page-envelope:publication-id}/{page-envelope:area}/{page-envelope:document-type}{page-envelope:document-url}"/> > <map:match pattern="authoring/**.html"> > <map:transform > src="cocoon://lenya-page/{page-envelope:publication-id}/{../../1}.xml?doctype={page-envelope:document-type}"/> > </map:match> > <map:transform src="../../xslt/util/strip_namespaces.xsl"/> > <map:match pattern="live/**.html"> > <map:transform > src="../../xslt/authoring/edit/addSourceTags.xsl"> > <map:parameter name="source" > value="{global:cache-dir}/live/{1}.html"/> > </map:transform> > <map:transform type="write-source"> > <map:parameter name="serializer" value="xhtml"/> > </map:transform> > <map:transform > src="../../xslt/authoring/edit/removeSourceTags.xsl"/> > </map:match> > <map:serialize type="xhtml"/> > </map:otherwise> > </map:select> > </map:act> > > <!-- There is no version of the requested document-id for the > requested language. --> > <map:generate type="serverpages" > src="../../content/exception/missing-language.xsp"/> > <map:transform src="../../xslt/exception/missing-language.xsl"/> > <map:call resource="style-cms-page"/> > > </map:match> > > I tested both by uncommenting the bad resource calls and validated the > entry into the pipelines per cocoon failing. > > So it seems I get into my desired pipeline (the first) but then enter > another (which checks to see if the resource exists, I don't want > that). So how do I prevent from entering the second pipeline? Again, > do I need to mount another sitemap? Will that divert processing away > from it or will processing return back to the calling sitemap leaving > me with the same problem? > > Thanks.
I don't have the time to study it closely right now, but I wonder if the pipeline that handles the cocoon:/body-headers.xml" URI generates some other request that takes the flow to the second pipeline above. One way to find out what is really going on is to set Lenya's logging level to debug. Then the path through the pipelines (including xmap file names & line numbers) is shown. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
