forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: JSPWiki and Forrest
Date Tue, 06 May 2003 11:18:19 GMT
On Mon, May 05, 2003 at 07:04:37PM +0200, Luca Morandini wrote:
> Folks,
> I'm trying to edit Forrest (as webapp) pages with JSPWiki... so far so 
> good, but:
> 1) How can I hide the "edit page" button when the site is generated via 
> Forrestbot ? I mean, I'd like having a parameter in my sitemap telling 
> me whether an URI has been called by a Forrestbot or not.

I think you mean the Cocoon command-line static rendering.  Forrestbot is
a dodgy cron+shell+XSLT+Ant affair running on

The only way I know of passing command-line parameters to Cocoon is by
replacing @tokens@ in cocoon.xconf.  This is how the skin is chosen
(a @skin@ token).  So yes, we could have an <online>@online@</online> tag
in cocoon.xconf, where @online@ gets replaced with 'yes' or 'no'
depending on whether we're in webapp or command-line mode.  Then in the
sitemap, {forrest:online} would be 'yes' or 'no', and that could be
passed to the XSLT.

Or maybe the new Cocoon cli.xconf allows parameters, which would make
things much simpler.

> 2) I'd like JSPWiki to use the "cwiki" extension instead of the usual 
> "txt"... does anyone know ?

We ought to make this configurable in Forrest.  The .cwiki extension
isn't very nice, but it does provide much-needed metadata.

> 3) BTW, does anyone know a Cocoon-based Wiki (JSPWiki is just fine, but 
> I'd like to have the same architecture for everything) ?

Wikiland.  It uses the radeox rendering engine from the very nice
snipsnap Wiki system:

which implements all sorts of wonderful stuff like code syntax
highlighting with {code:java}, javadoc links {api:...} etc:

The neat thing is that we could replicate much of the Wiki macro system
with a series of preprocessing XSLTs.  No custom APIs like radeox, just
XML pipelines and components manipulating XML from cocoon: URLs.

On this theme..

Paul Prescod wrote:

"Any business problem can be thought of as a data resource manipulation
problem" [1]

The Cocoon approach is "get the problem into 'data resource
manipulation' mode ASAP".  Like Chaperon; forget trying to define an
API for an abstract syntax tree, just output XML.  When tempted to write
a Java API, instead write a schema.  They're both contracts, but XML's
looser coupling combined with powerful Cocoon manipulation tends to make
for a simpler and more flexible system.  See also "APIs Considered

</offtopic rant> :)


> Regards,
> ------------------------------------------
>                Luca Morandini
>                GIS Consultant
> ------------------------------------------

View raw message