You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Luca Morandini <lu...@tin.it> on 2003/05/05 19:04:37 UTC
JSPWiki and Forrest
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.
2) I'd like JSPWiki to use the "cwiki" extension instead of the usual
"txt"... does anyone know ?
3) BTW, does anyone know a Cocoon-based Wiki (JSPWiki is just fine, but
I'd like to have the same architecture for everything) ?
Regards,
------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://space.virgilio.it/kumora/index.html
------------------------------------------
Re: JSPWiki and Forrest
Posted by Luca Morandini <lu...@tin.it>.
Jeff Turner wrote:
> I think you mean the Cocoon command-line static rendering. Forrestbot is
> a dodgy cron+shell+XSLT+Ant affair running on forrestbot.cocoondev.org.
Yes, I meant the command-line rendering. Ahem... I thought they were the
same thing: thanks for enlightening me.
>
> 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.
>
Thanks, I'll try it. BTW, could someone insert such a switch in the next
Forrest release ?
I presume it could be useful to many.
> 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"
Right on target ! I'll shamelessy borrow this quote for a Cocoon course
I'm going to teach :)
Regards,
------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://space.virgilio.it/kumora/index.html
------------------------------------------
Re: JSPWiki and Forrest
Posted by Stephan Michels <st...@apache.org>.
On Tue, 6 May 2003, Jeff Turner wrote:
> On Mon, May 05, 2003 at 07:04:37PM +0200, Luca Morandini wrote:
>
> > 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:
>
> http://snipsnap.org/space/start
>
> which implements all sorts of wonderful stuff like code syntax
> highlighting with {code:java}, javadoc links {api:...} etc:
>
> http://snipsnap.org/space/snipsnap-help
>
> <offtopic>
> 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
> Harmful", http://www.itworld.com/nl/xml_prac/04182002/pf_index.html
>
> </offtopic rant> :)
Well said!
BTW, I would love to see a Cocoon version of a Wiki system. At the moment
I trying to get all things together (Cocoon + Forrest + Chaperon +
XMLForm), but I didn't come straight forward.
Stephan.
Re: JSPWiki and Forrest
Posted by Jeff Turner <je...@apache.org>.
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 forrestbot.cocoondev.org.
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:
http://snipsnap.org/space/start
which implements all sorts of wonderful stuff like code syntax
highlighting with {code:java}, javadoc links {api:...} etc:
http://snipsnap.org/space/snipsnap-help
<offtopic>
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
Harmful", http://www.itworld.com/nl/xml_prac/04182002/pf_index.html
</offtopic rant> :)
--Jeff
> Regards,
>
> ------------------------------------------
> Luca Morandini
> GIS Consultant
> lmorandini@ieee.org
> http://space.virgilio.it/kumora/index.html
> ------------------------------------------
>
>