cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Upayavira">
Subject Re: CLI question: how are links retrieved?
Date Sun, 18 May 2003 15:41:21 GMT

> > Just to note - you can still use the old method with the CLI (i.e.
> > requesting each page 3 times), the option is still there to do it
> > just the same as it was. In fact, I believe that is the default
> > behaviour.
> Thanks, didn't know that.  I've gotten Forrest working this way now.

> > In the new behaviour, it does not use the links view, it uses a
> > 'LinkGatherer' which collects the links and stores them in the
> > ObjectModel for later use by the CLI. This is done in the
> > org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode
> > class, at the same point as the old-style CLI rewrites its links.
> > The links are gathered right at the end of the pipeline, just before
> > the serializer, I believe.
> So say I use multiple pipelines to generate a response:
> <map:match pattern="index.html">
>   <map:aggregate>
>     <map:part src="cocoon:/body-index.xml"/>
>     ...
>   <map:serialize type="html"/>
> </map:match>
> <map:match pattern="body-index.xml">
>   <map:generate src="cocoon:/index.xml"/>
>   <map:transform src="linkrewriter" .../>
>   ...
>   <map:serialize type="xml"/>
> </map:match>
> <map:match pattern="index.xml">
>   <map:generate src="content/xdocs/index.xml"/>
>   ...
>   <map:serialize type="xml"/>
> </map:generate>
> Which pipeline would the links be sampled from?  I'm speculating that
> the first serializer to be invoked (index.xml) writes the links to the
> object model.  This would explain what I'm seeing, as links are only
> rewritten in the second pipeline.

I managed to get it working by following the way the LinkTranslator works and adding 
in a LinkGatherer at the same point (within the 
o.a.c.components.treeprocessor.sitemap.SerializeNode class, invoke method, search 
for "<gatherer>").

Having said that, I would expect that a serializer should not be called for cocoon: 
pipelines, so there should only be one single serializer called anyway, which is the 
last one as you would expect.

> > So they should have been translated by then, Is that not happening?
> > Can you explain a little more what is supposed to be happening?
> As shown above, there is a three-layer sitemap.  The 'linkrewriter'
> transformer converts tags like <a href="site:index"> to <a
> href="../index.html">.  They're not being converted when using the
> 'cli.xconf' CLI.

Hmm. That doesn't sound right.

How easy is it for you to send me a site for me to have a look at and try? A zip or 
tarball of a site complete with sitemap? I've often felt starved of good sites to use 
when testing the CLI, and a decent Forrest site would be very useful.

> > I'm thinking of adding 'exclude' and 'include' options to the 
> > cli.xconf, so that you can exclude as necessary. Would that address
> > your needs?
> It would.  I quite like the 'links view' system though.  Doing link
> manipulation in a Cocoon pipeline seems generally more flexible than
> adding cli.xconf parameters, and is much easier to debug with
> ?cocoon-view=links

I can appreciate that. The problem is that if you use a link view, you need to generate 
the page multiple times - once for the content, once for the link view. If you want 
single pass link gathering, you can't have a link view. Simple as that, as far as I can 
see. Do say if you can think of another way. And, both options are available in the 
current CLI.

At some point, I've got to document all of this. I'll do this once I've finished debugging

my latest set of changes (writing using sources and using if-modified-since).

Exclude and include will allow something approaching the linkmap flexibility when 
you're only generating the page once.

> > > Perhaps as a result of 1), I get lots of these stacktraces:
> > > 
> > > java.lang.NullPointerException
> > >         at
> > >         org.apache.cocoon.environment.AbstractEnvironment.release(
> > >         Abst at
> > 
> > Bleurgh. Don't know where to start on that one. But lets look at the
> > above and see if that helps.
> Further digging shows it happening when a <map:redirect-to> is
> encountered.  Attached is a small diff demonstrating this for 'build
> docs' in Cocoon.  I'll file a bugreport to keep track of this.

Hmm. I'm not sure what happens with redirects in the CLI. 

Are you saying that it works when you use the links view, and fails with the single 
pass version? 

> Thanks for your help!

You're welcome. It's good to have someone testing it!!

Regards, Upayavira

View raw message