RE: JSR 168 in new portal
You have to enable cross context access for Cocoon. Add a cocoon.xml in the webapps directory with the following content: Then it should work. HTH Carsten > -Original Message- > From: Grofcík Martin [mailto:[EMAIL PROTECTED] > Sent: Friday, June 25, 2004 8:09 AM > To: [EMAIL PROTECTED] > Subject: RE: JSR 168 in new portal > > The version of the Tomcat is 4.1.30. > > Pluto (version 1.0.1) was build and deployed by maven rc1. > (maven fullDeployment command). > > Then I check pluto instalation - test portlets were OK. > > I stopped tomcat. > I unpacked cocoon war into the tomcat's webapps dir and > removed pluto*.jar and porlet-api*.jar. > I start Tomcat. And there were no output for test portlet #1, #2. > > > > -Original Message- > From: Menke, John [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 24, 2004 4:44 PM > To: '[EMAIL PROTECTED]' > Subject: RE: JSR 168 in new portal > > >>I deployed cocoon app as JSR 168 compatibile portlet into > the pluto. > > What version of Tomcat are you using? > You deployed by creating the .war and putting it in the > webapp folder right? > > i am using 4.1.30 and Cocoon is not coming up > > -jm > > __ Informacia od NOD32 1.574 (20031206) __ > > Tato sprava bola preverena antivirusovym systemom NOD32. > http://www.eset.sk > > >
RE: JSR 168 in new portal
Thak you a lot. It helps. Regards Martin -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Friday, June 25, 2004 10:27 AM To: [EMAIL PROTECTED] Subject: RE: JSR 168 in new portal You have to enable cross context access for Cocoon. Add a cocoon.xml in the webapps directory with the following content: Then it should work. HTH Carsten > -Original Message- > From: Grofcík Martin [mailto:[EMAIL PROTECTED] > Sent: Friday, June 25, 2004 8:09 AM > To: [EMAIL PROTECTED] > Subject: RE: JSR 168 in new portal > > The version of the Tomcat is 4.1.30. > > Pluto (version 1.0.1) was build and deployed by maven rc1. > (maven fullDeployment command). > > Then I check pluto instalation - test portlets were OK. > > I stopped tomcat. > I unpacked cocoon war into the tomcat's webapps dir and removed > pluto*.jar and porlet-api*.jar. > I start Tomcat. And there were no output for test portlet #1, #2. > > > > -Original Message- > From: Menke, John [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 24, 2004 4:44 PM > To: '[EMAIL PROTECTED]' > Subject: RE: JSR 168 in new portal > > >>I deployed cocoon app as JSR 168 compatibile portlet into > the pluto. > > What version of Tomcat are you using? > You deployed by creating the .war and putting it in the webapp folder > right? > > i am using 4.1.30 and Cocoon is not coming up > > -jm > > __ Informacia od NOD32 1.574 (20031206) __ > > Tato sprava bola preverena antivirusovym systemom NOD32. > http://www.eset.sk > > > __ Informacia od NOD32 1.574 (20031206) __ Tato sprava bola preverena antivirusovym systemom NOD32. http://www.eset.sk
Re: Playing with the JCR RI
Stefano Mazzocchi wrote:
Ugo Cei wrote:
Il giorno 24/giu/04, alle 18:23, Stefano Mazzocchi ha scritto:
But I do think it makes sense to have general pipeline components
that are able to read and write into a JCR repository anyway, but
probably a Source would be better in this regard.
Hmmm, I thought you were somewhat contrary to writable sources, or
did I misunderstood?
I'm talking about reading stuff out of a JCR repository.
yes, I'm not keen to writeable sources.
I don't see why there's a problem with writeable sources per se. The
problem IMO comes more from the SourceWritingTransformer, which modifies
the system state (by writing somewhere) as a side effect of the pipeline
processing.
But writeable soures used in the business logic and/or flowscript just
rock, and make it braindead easy to write data to anyone of file, cvs
repo, SQL blob, etc.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Throwing errors in component's initialize() method
Hello, I've written a component which uses native code. Therefore it needs to load native libraries (I do this in the initialize() method) and when something goes wrong with that, Errors get thrown (e.g. UnsatisfiedLinkError). But Cocoon doesn't seem to recognize this, and it looks like Cocoon starts up normally. When some pipeline is invoked, it seems that Cocoon is going to reconfigure/initialize itself, resulting in even more errors (e.g. HSQLDB that is already started, etc.) Is this the desired behaviour? Should I catch any error and rethrow it inside some exception, so that Cocoon correctly handles the failure? Or is there any way that Cocoon can catch these errors? Bart.
Re: [RT] The Cocoon Handbook
Tony Collen wrote:
This is a late-night, rambling [RT]. I think it's a good idea. You
may or may not. Please flame, argue, discuss, rant, etc... it's an
[RT], after all... Have fun!
>> The Problem: Documentation <<
Right here is where I would discuss the problem in a more in-depth
sort of way, but since my brain is pretty much shut down, that's not
going to happen. Insert your own rambling explanation of why the docs
stink. ;)
>> The Solution <<
I propose we create a free, high-quality electronic book (entitled
_The_Cocoon_Handbook_), which will eventually replace the mess of docs
we currently have.
A big +1.
It will be in DocBook (possibly simplified) format.
Not only are we having a hard enough time keeping the documentation
up-to-date normally, fightning the rampant wiki spamming has become
almost a full-time job as it is.
We can integrate the eventual book with user-added notations, similar
to how PHP lets people log in and annotate the existing docs.
There are two main problems that IMO explain the poor state of Cocoon docs.
The first one is that Cocoon being a large beast, it's doc has to be
large, and therefore needs a well-defined structure. There has been
various attemps made which need to be continued, one problem being that
it seems whe have some fears to change the structure (or lack thereof)
of the current docs.
The second one is that writing docs in XML is a major PITA, futhermore
when we have fancy word processors just a click away on our computers.
I'm sure that it refrains many prople from writing docs (including me).
Intermediate tools like XXE ease the job, but aren't as userfriendly as
good old MS Word. Simplified syntaxes as wiki are good for small
documents (i.e. a page) but IMO don't scale for large structured
documentations.
Now we have that nice thing called OpenOffice that is a wordprocessor
storing its content as XML in a zip archive. We've used it as a
front-end for a CMS, providing template documents with style sheets that
have to be used. These styles match the structure of the target XML
document that is produced from the OO file. This solution just rocks, as
anybody (even a boss :-) is able to write content in a userfriendly and
productive environment with spell checking, typing completion, etc etc.
On the CMS side, the sxw archive is exploded, the XML content is
transformed into the target markup (e.g. DocBook) and images are stored.
Sure, for the Cocoon docs, we cannot wait to have a CMS setup and ready,
or we'll never have docs ;-) What is rather simple, however, is to have
some offline processing (based on the CLI) that would do the
exploding/recomposition job to allow editing Cocoon docs with a real
wordprocessor.
Yes, talking about technology rather than about writers, but IMO writers
will come if they can use productive tools for the job.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Throwing errors in component's initialize() method
Bart Molenkamp wrote:
Hello,
I've written a component which uses native code. Therefore it needs to
load native libraries (I do this in the initialize() method) and when
something goes wrong with that, Errors get thrown (e.g.
UnsatisfiedLinkError). But Cocoon doesn't seem to recognize this, and it
looks like Cocoon starts up normally. When some pipeline is invoked, it
seems that Cocoon is going to reconfigure/initialize itself, resulting
in even more errors (e.g. HSQLDB that is already started, etc.)
Is this the desired behaviour? Should I catch any error and rethrow it
inside some exception, so that Cocoon correctly handles the failure? Or
is there any way that Cocoon can catch these errors?
Cocoon catches only Exceptions, and not Errors. So the best way is what
you propose: catch the Error in your initialize() and retrow it,
cascaded in an Exception.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: Throwing errors in component's initialize() method
Ok, thanks,
But could you tell me why it catches only exceptions, and not errors?
(Just interested).
Bart.
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: Friday, June 25, 2004 12:44 PM
To: [EMAIL PROTECTED]
Subject: Re: Throwing errors in component's initialize() method
Bart Molenkamp wrote:
>Hello,
>
>I've written a component which uses native code. Therefore it needs to
>load native libraries (I do this in the initialize() method) and when
>something goes wrong with that, Errors get thrown (e.g.
>UnsatisfiedLinkError). But Cocoon doesn't seem to recognize this, and
it
>looks like Cocoon starts up normally. When some pipeline is invoked, it
>seems that Cocoon is going to reconfigure/initialize itself, resulting
>in even more errors (e.g. HSQLDB that is already started, etc.)
>
>Is this the desired behaviour? Should I catch any error and rethrow it
>inside some exception, so that Cocoon correctly handles the failure? Or
>is there any way that Cocoon can catch these errors?
>
>
Cocoon catches only Exceptions, and not Errors. So the best way is what
you propose: catch the Error in your initialize() and retrow it,
cascaded in an Exception.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
OpenOffice frontend for CMS (was: [RT] The Cocoon Handbook)
Hi Sylvain, On 25 Jun 2004, at 11:42, Sylvain Wallez wrote: Now we have that nice thing called OpenOffice that is a wordprocessor storing its content as XML in a zip archive. We've used it as a front-end for a CMS, providing template documents with style sheets that have to be used. These styles match the structure of the target XML document that is produced from the OO file. This solution just rocks, as anybody (even a boss :-) is able to write content in a userfriendly and productive environment with spell checking, typing completion, etc etc. On the CMS side, the sxw archive is exploded, the XML content is transformed into the target markup (e.g. DocBook) and images are stored. That's an inspired solution - is it all proprietary or is your code published somewhere? Cheers, Jon
Re: [RT] The Cocoon Handbook
Sylvain Wallez wrote: Now we have that nice thing called OpenOffice that is a wordprocessor storing its content as XML in a zip archive. We've used it as a front-end for a CMS, providing template documents with style sheets that have to be used. These styles match the structure of the target XML document that is produced from the OO file. This solution just rocks, as anybody (even a boss :-) is able to write content in a userfriendly and productive environment with spell checking, typing completion, etc etc. On the CMS side, the sxw archive is exploded, the XML content is transformed into the target markup (e.g. DocBook) and images are stored. Sure, for the Cocoon docs, we cannot wait to have a CMS setup and ready, or we'll never have docs ;-) What is rather simple, however, is to have some offline processing (based on the CLI) that would do the exploding/recomposition job to allow editing Cocoon docs with a real wordprocessor. It would be simplier to store docs in sxw file itself; no recomposition is necessary, and html/pdf publishing out of sxw "repository" can be added to forrest. Vadim
Re: Serious FlowScript problem
Hi, On 24 Jun 2004, at 13:49, Jeremy Quinn , Jeremy Quinn wrote: Thanks for your suggestion, but context:// has never been an issue for me in the past. There has been a bug in the latest CVS for the last few weeks, that Carsten fixed yesterday. Have you tested your app again with the latest HEAD? Might well be unrelated to your problem, but worth trying. Cheers, Jon
Re: [RT] The Cocoon Handbook
Vadim Gritsenko wrote: Sylvain Wallez wrote: Now we have that nice thing called OpenOffice that is a wordprocessor storing its content as XML in a zip archive. We've used it as a front-end for a CMS, providing template documents with style sheets that have to be used. These styles match the structure of the target XML document that is produced from the OO file. This solution just rocks, as anybody (even a boss :-) is able to write content in a userfriendly and productive environment with spell checking, typing completion, etc etc. On the CMS side, the sxw archive is exploded, the XML content is transformed into the target markup (e.g. DocBook) and images are stored. Sure, for the Cocoon docs, we cannot wait to have a CMS setup and ready, or we'll never have docs ;-) What is rather simple, however, is to have some offline processing (based on the CLI) that would do the exploding/recomposition job to allow editing Cocoon docs with a real wordprocessor. It would be simplier to store docs in sxw file itself; no recomposition is necessary, and html/pdf publishing out of sxw "repository" can be added to forrest. I believe Reinhard added it a while ago. Upayavira
Re: Serious FlowScript problem
On 25 Jun 2004, at 12:29, Jon Evans wrote: Hi, On 24 Jun 2004, at 13:49, Jeremy Quinn , Jeremy Quinn wrote: Thanks for your suggestion, but context:// has never been an issue for me in the past. There has been a bug in the latest CVS for the last few weeks, that Carsten fixed yesterday. Have you tested your app again with the latest HEAD? Might well be unrelated to your problem, but worth trying. Thanks for the suggestion. By coincidence I did a fresh checkout this morning and the problem still exists. The really strange thing is, I can see this happening with our own FlowScripts in our own Project. I have never seen this problem with any of the FlowScripts in Cocoon Samples (except that incident when I loaded a Cocoon flowscript via context://). So, 2 possible clues: * project mounted via a full filesystem path (though I did try mounting it inside cocoon/build/webapp and I *did* get failures) * maybe has a basis in Sessions, because one client may fail while another does not. Thanks regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
Re: Serious FlowScript problem
Le 25 juin 04, à 13:42, Jeremy Quinn a écrit : ...The really strange thing is, I can see this happening with our own FlowScripts in our own Project. I have never seen this problem with any of the FlowScripts in Cocoon Samples (except that incident when I loaded a Cocoon flowscript via context://)... FYI I'm pretty sure that I've seen this at some point in the last 6 weeks, IIRC while using rsync scripts to copy stuff from my source repository to the webapp dir of a running Cocoon. At the time I had the feeling that the live updating of stuff was related to what was happening. I don't remember the details now as it only happened once or twice and I moved on, but I've had some unexplained "XXX is not a function" errors while the function was indeed there. Sorry that I cannot be more precise, just wanted to let you know that there have been other appearances of this alien life form ;-) -Bertrand
OpenJMS vs. ActiveMQ
Dear Cocooners, currently our JMS block, to be actually working, requires that one: - download and install a JMS client library, which we don't distribute for licensing reasons - have a running instance of a JMS server in another VM This is not very comfortable, isn't it? But today I stumbled upon this [1]: "ActiveMQ is an open source, Apache 2.0 licenced Message Broker and JMS 1.1 implementation which integrates seamlessly into Geronimo, light weight containers and any Java application. [ActiveMQ] can be used as an in memory JMS provider, ideal for unit testing." So I though we could use that and have a working JMS provider out-of-the-box, immediately usable by blocks that need one (slide, eventcache). Since I have zero knowledge of JMS-related matters and am too busy toying with the JCR, Slide, Hibernate and various petstores, I'm just suggesting that someone with the necessary expertise and free time look after it. WDYT? Ugo P.S.: personally, I'm not that interested in JMS per se, but what I read about Streamlets [2] has tickled my curiosity. Sounds cool, doesn't it? [1] http://activemq.codehaus.org/ [2] http://activemq.codehaus.org/Streamlets -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Getting the Context Path inside a FormValidator
Is it possible to get the context path where a application is running from within a FormValidator in CForms ? Maybe there is a way to get a servicemanager using a static method from any class i do not know ... Somebody out there able helping me ? THX Andreas Schmid
RE: [RT] The Cocoon Handbook - some actions
Guys, I've seen many discussions and nice ideas, but so far only suggestions. Here is my compilation of these suggestions: 1. Nicola offered to set up a space for the documents using Forrest. Given other remarks it should be possible/easy to convert any structured electronic text to something useable for Forrest. So let's do this. 2. Nicola also suggested to put this in SVN, which allows more fine-grained access for docs-only committers. Sounds good and would be a nice testcase for those wanting to work with SVN. So let's do this too. 3. The idea to start out with an outline has been suggested in the past too (a.o. by yours truly :-)). Let's sweep these efforts together and come up with a rough outline. This is by no means final, otherwise there will be discussions for the coming year on what the BEST outline is. It's a start and can be used for the first version. I will do this. 4. It's a good idea to add existing docs to the new outline, although each and every part has to be reviewed to see if it is still correct, but in terms of getting it up and running this is by far quicker than a rewrite from scratch. 5. Using OpenOffice with suitable templates should indeed attrack more writers. So for now, let's make some decisions based on the suggestions above. If it was me I would take these ACTIONS: 1. Nicola sets up a document space. 2. Nicola sets up a SVN access to this space. 3. I will gather all efforts to create an outline and merge them to something that look reasonable. 4. Sylvain creates/modifies a template to be used in OpenOffice. 5. Someone (Nicola?) writes a small HOW-TO use SVN for documentation. 6. Someone (Sylvain?) writes a small HOW-TO use OpenOffice + template for documentation. ... more actions to come. WDYT? Bye, Helma
Re: [RT] The Cocoon Handbook
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Now we have that nice thing called OpenOffice that is a wordprocessor
storing its content as XML in a zip archive. We've used it as a
front-end for a CMS, providing template documents with style sheets
that have to be used. These styles match the structure of the target
XML document that is produced from the OO file. This solution just
rocks, as anybody (even a boss :-) is able to write content in a
userfriendly and productive environment with spell checking, typing
completion, etc etc. On the CMS side, the sxw archive is exploded,
the XML content is transformed into the target markup (e.g. DocBook)
and images are stored.
Sure, for the Cocoon docs, we cannot wait to have a CMS setup and
ready, or we'll never have docs ;-) What is rather simple, however,
is to have some offline processing (based on the CLI) that would do
the exploding/recomposition job to allow editing Cocoon docs with a
real wordprocessor.
It would be simplier to store docs in sxw file itself; no
recomposition is necessary, and html/pdf publishing out of sxw
"repository" can be added to forrest.
The problem is that it requires storing the sxw as a binary file, which
doesn't help to track changes.
A mid-term solution can be to dezip the sxw and store it's various
components as is. The exploding/recomposition process would then simply
be unzip/zip.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Throwing errors in component's initialize() method
Bart Molenkamp wrote:
Ok, thanks,
But could you tell me why it catches only exceptions, and not errors?
(Just interested).
Because, quoting the Javadoc, "An Error is a subclass of Throwable that
indicates serious problems that a reasonable application should not try
to catch."
This has been discussed several times (dig the archives for
"Throwable"), and IIRC the conclusion was that the only error that would
make sense for Cocoon to catch is OutOfMemoryError.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: OpenOffice frontend for CMS
Jon Evans wrote:
Hi Sylvain,
On 25 Jun 2004, at 11:42, Sylvain Wallez wrote:
Now we have that nice thing called OpenOffice that is a wordprocessor
storing its content as XML in a zip archive. We've used it as a
front-end for a CMS, providing template documents with style sheets that
have to be used. These styles match the structure of the target XML
document that is produced from the OO file. This solution just rocks, as
anybody (even a boss :-) is able to write content in a userfriendly and
productive environment with spell checking, typing completion, etc etc.
On the CMS side, the sxw archive is exploded, the XML content is
transformed into the target markup (e.g. DocBook) and images are stored.
That's an inspired solution - is it all proprietary or is your code
published somewhere?
It's proprietary, but some basic blocks that were needed to build it are
now in Cocoon: ZipArchiveSerializer, CVSSource (at cocoondev.org), some
parts of Cocoon Forms, etc.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
[ANN] Radeox wiki parser available under ASL 2.0 license
Big thanks to the Radeox team! They have agreed to re-license Radeox under the ASL 2.0 license, so that we can distribute it in Cocoon. As I'm leaving soon for the Big Trip, I won't be able to work on the integration, but if someone's available you'll find the details below. Stephan Schmidt would like to be informed when the integration happens, to let the world now via radeox.org. -Bertrand Début du message réexpédié : De: "Stephan J. Schmidt" <[EMAIL PROTECTED]> Date: 25 juin 2004 14:11:28 GMT+02:00 À: Bertrand Delacretaz <[EMAIL PROTECTED]> Objet: Radeox ASL 2.0 Hi Betrand, here is a Radeox distribution with Apache 2.0 license. http://tanis.first.fraunhofer.de/~stephan/radeox-1.0-BETA-2-src.tgz This is not released yet, just for cocoon right now. Have fun, bye -stephan -- SnipSnap http://snipsnap.org An easy to use and easy to install weblog and wiki software. Fraunhofer - Institute for Computer Architecture and Software Technology Stephan J. Schmidt, Fraunhofer FIRST, Kekulestr 7, 12489 Berlin, Germany FON +49 (0)30 6392 1822, FAX -1805, [EMAIL PROTECTED]
Leasson learned (was: Looking for a block name: forum, vote, poll components)
Hi folks, I should have learned before that pre-annoucing stuff usually does not work ;-( I won't have enough time before the Big Trip to contribute the forum components as (more or less) promised, sorry. So, unless someone beats me to it, it won't be before the end of August. -Bertrand Le 18 juin 04, à 10:21, Bertrand Delacretaz a écrit : Hi Cocoonistas, I have to implement a simple discussion forum, voting (to rate articles) and simple polls for a project that I'm working on, and I'm hoping to be able to contribute these components as a new block before I leave for the Big Trip
Re: OpenOffice frontend for CMS
Hi Sylvain, On 25 Jun 2004, at 14:15, Sylvain Wallez wrote: It's proprietary, but some basic blocks that were needed to build it are now in Cocoon: ZipArchiveSerializer, CVSSource (at cocoondev.org), some parts of Cocoon Forms, etc. OK, cheers. It sounds like an idea worth pursuing here for a web app we're developing. Thanks, Jon
Re: Leasson learned
Bertrand Delacretaz wrote:
Hi folks,
I should have learned before that pre-annoucing stuff usually does not
work ;-(
I won't have enough time before the Big Trip to contribute the forum
components as (more or less) promised, sorry.
So, unless someone beats me to it, it won't be before the end of August.
No problem, we can live without them until August... but not much after
;-P
Enjoy you trip,
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: OpenOffice frontend for CMS
Sylvain Wallez wrote: Jon Evans wrote: Hi Sylvain, On 25 Jun 2004, at 11:42, Sylvain Wallez wrote: Now we have that nice thing called OpenOffice that is a wordprocessor storing its content as XML in a zip archive. We've used it as a front-end for a CMS, providing template documents with style sheets that have to be used. These styles match the structure of the target XML document that is produced from the OO file. This solution just rocks, as anybody (even a boss :-) is able to write content in a userfriendly and productive environment with spell checking, typing completion, etc etc. On the CMS side, the sxw archive is exploded, the XML content is transformed into the target markup (e.g. DocBook) and images are stored. That's an inspired solution - is it all proprietary or is your code published somewhere? It's proprietary, but some basic blocks that were needed to build it are now in Cocoon: ZipArchiveSerializer, CVSSource (at cocoondev.org), some parts of Cocoon Forms, etc. Sylvain It is possible to use OpenOffice-Writer documents in Forrest - see the examples after seeding a new Forrest project. For me this works well. I think this could be interesting for Cocoon too. Currently the .sxw docs are stored and during the rendering process the ZIPSource is used to extract the content and create the documentation. -- Reinhard, writing this without reading the whole thread
Re: [RT] The Cocoon Handbook
Sylvain Wallez wrote: Vadim Gritsenko wrote: Sylvain Wallez wrote: Now we have that nice thing called OpenOffice that is a wordprocessor storing its content as XML in a zip archive. We've used it as a front-end for a CMS, providing template documents with style sheets that have to be used. These styles match the structure of the target XML document that is produced from the OO file. This solution just rocks, as anybody (even a boss :-) is able to write content in a userfriendly and productive environment with spell checking, typing completion, etc etc. On the CMS side, the sxw archive is exploded, the XML content is transformed into the target markup (e.g. DocBook) and images are stored. Sure, for the Cocoon docs, we cannot wait to have a CMS setup and ready, or we'll never have docs ;-) What is rather simple, however, is to have some offline processing (based on the CLI) that would do the exploding/recomposition job to allow editing Cocoon docs with a real wordprocessor. It would be simplier to store docs in sxw file itself; no recomposition is necessary, and html/pdf publishing out of sxw "repository" can be added to forrest. The problem is that it requires storing the sxw as a binary file, which doesn't help to track changes. A mid-term solution can be to dezip the sxw and store it's various components as is. The exploding/recomposition process would then simply be unzip/zip. Another way could be storing the whole document as one file by using import/export filters that creates a single XML document and you don't have to deal with the whole bunch of docs. -- Reinhard
NOTICE: Wiki editing
Hi folks, Due to excessive spamming and a impending migration to the Apache Wiki, the Cocoon Wiki is currently set to "fake read-only". If you want to edit pages on the Wiki, please poll the PMC list ([EMAIL PROTECTED]) for details. Thanks, -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java & XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [RT] The Cocoon Handbook
Sylvain Wallez wrote: Now we have that nice thing called OpenOffice that is a wordprocessor storing its content as XML in a zip archive. We've used it as a front-end for a CMS, providing template documents with style sheets that have to be used. These styles match the structure of the target XML document that is produced from the OO file. This solution just rocks, as anybody (even a boss :-) is able to write content in a userfriendly and productive environment with spell checking, typing completion, etc etc. On the CMS side, the sxw archive is exploded, the XML content is transformed into the target markup (e.g. DocBook) and images are stored. Hmm, how is OpenOffice on Win32? I've never ever used it, so it would be something new for me to pick up.. not like using office software is hard or anything. I'd be worried about usability or whatever. I suppose I'll download it and play with it. Tony
Re: [RT] The Cocoon Handbook
Sylvain Wallez wrote: ... The problem is that it requires storing the sxw as a binary file, which doesn't help to track changes. Come on guys HTML, HTML, HTML! Forrest *already* can use HTML! -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Cocoon Docs SVN Repository?
To start off the new documentation effort, I'd like to use subversion and html. This would give us the possibility of simply navigating the latest docs in source control in an easy way, and given how well tortoiseSVN works also to make it easier for doc writers. Is it ok if I ask infrastructure to create a cocoon/newdocs space in svn so we can start working on it? Later on it can be moved under the final cocoon destination with no effort (thanks to SVN :-) WDOT? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] The Cocoon Handbook
Sylvain Wallez wrote: ... The problem is that it requires storing the sxw as a binary file, which doesn't help to track changes. Come on guys HTML, HTML, HTML! Forrest *already* can use HTML! -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Cocoon Docs SVN Repository?
Nicola Ken Barozzi wrote: To start off the new documentation effort, I'd like to use subversion and html. +1. I would also like to see how well XHTML2 works for this, but I know Forrest doesn't support it yet. I like the idea of using some sort of "nice" editor (e.g. OpenOffice), but I think it would be best to just stick to something basic. I guess the problem with writing in DocBook is that you'd need a fancy XML editor in order to be productive... so let's keep it simple for now. This would give us the possibility of simply navigating the latest docs in source control in an easy way, and given how well tortoiseSVN works also to make it easier for doc writers. Is it ok if I ask infrastructure to create a cocoon/newdocs space in svn so we can start working on it? Later on it can be moved under the final cocoon destination with no effort (thanks to SVN :-) +1. A few random questions: What is the status of the apache.org Wiki? Is it stable & usable? We could start fleshing out docs stuff over there. Should we have a cocoon-docs subwiki, or should we just consider the whole thing the docs? Should we be coordinating all this on -docs? Tony
Re: Getting the Context Path inside a FormValidator
On 25.06.2004 14:44, Andreas Schmid wrote: Is it possible to get the context path where a application is running from within a FormValidator in CForms ? Maybe there is a way to get a servicemanager using a static method from any class i do not know ... Somebody out there able helping me ? IIUC you only need a source resolver and resolve the path "context://". Joerg
Re: [RT] The Cocoon Handbook
On 25.06.2004 18:09, Tony Collen wrote: Hmm, how is OpenOffice on Win32? I've never ever used it, so it would be something new for me to pick up.. not like using office software is hard or anything. I'd be worried about usability or whatever. I suppose I'll download it and play with it. I was never a hardcore Word user, so I can not tell you all the differents in detail. But I wrote seminar papers with both Word and Open Office. My personal preference __tends__ to Open Office since I had the __feeling of better control__ of my document. Word does to much auto-magic and shows strange behaviour, therefore I did not find out how to do page numbering correctly with different styles for different parts in the document using OO. Joerg
Re: [RT] The Cocoon Handbook
On 25.06.2004 19:12, Nicola Ken Barozzi wrote: The problem is that it requires storing the sxw as a binary file, which doesn't help to track changes. Come on guys HTML, HTML, HTML! Forrest *already* can use HTML! Why that low-level? You don't have a real page structure then, it's to loose IMO. Joerg
Re: [RT] The Cocoon Handbook
On 24.06.2004 20:00, Nicola Ken Barozzi wrote: IMHO the real thing we need is structure for others to fill in. Cocoon has a lot of docs, both on the site and on the Wiki, but it's hard to find them. Don't forget Helma's effort on that: http://wiki.cocoondev.org/Wiki.jsp?page=Cocoon215TOC Joerg
Re: [RT] The Cocoon Handbook
On 24.06.2004 17:54, Berin Loritsch wrote: It really doesn't matter how it is written as long as the information > gets out there. I tend to Sylvain's POV: Yes, talking about technology rather than about writers, but IMO writers will come if they can use productive tools for the job. Heck, use Wiki format to rough it in! It's easy and you don't have to worry about this tag or that. The Wiki format is ugly, different for every Wiki and difficult for more sophisticated tasks like internal linking. How do you reference a specific section? What happens if you move it around? Joerg
Re: [RT] The Cocoon Handbook
Ok, after I have shoot on most of the proposals I guess I must provide better alternatives :) My two alternatives for "large structured documentations" already have been mentioned: DocBook and Open Office. >> The Solution << I propose we create a free, high-quality electronic book (entitled _The_Cocoon_Handbook_), which will eventually replace the mess of docs we currently have. A big +1. I also like the DocBook way very much, we did it that way at Virbus. Customer requirement specifications and other documents were written using DocBook and transformed using customized DocBook stylesheets into Virbus CI PDFs. There are two main problems that IMO explain the poor state of Cocoon docs. The first one is that Cocoon being a large beast, it's doc has to be large, and therefore needs a well-defined structure. Again my pointer on Helma's TOC effort: http://wiki.cocoondev.org/Wiki.jsp?page=Cocoon215TOC. It's a good starting point IMO. The second one is that writing docs in XML is a major PITA, futhermore when we have fancy word processors just a click away on our computers. I'm sure that it refrains many prople from writing docs (including me). Intermediate tools like XXE ease the job, but aren't as userfriendly as good old MS Word. We did it the XXE way at Virbus, it works really good, but it's of course a developer's way, not a documentor's way. Simplified syntaxes as wiki are good for small documents (i.e. a page) but IMO don't scale for large structured documentations. Yes, Wiki and HTML just can not work IMO. There is no editor available for writing documentation with them. It starts with internal linking, goes on with loose structure and ends with ... I don't know :) Now we have that nice thing called OpenOffice that is a wordprocessor storing its content as XML in a zip archive. We've used it as a front-end for a CMS We too, but at a very low level. WDYT? I can live with both OO and DocBook. While the latter one is really straight forward for us, we will probably not really attract documentors, even with some fancy editors like XXE as the usability is not as good as with OO. But maybe that's only because the documentor must have the document structure in mind. With OO it is much more difficult for us to process the results. The documents are loose structured in the same way as HTML (no tree), but in contrary to HTML there is at least support for requirements like internal linking. A stylesheet processing those documents and adding the structure will be really hard (massive Muenchian Grouping), but not impossible of course. Therefore it's much easier for the documentor. I would be interested how you did the templates, Sylvain, to see if this solves problems of the post processing. The fact that OO files are not straight XML, but zipped XML, I would ignore. It's easy for us to do zip/unzip automatically. We only must not store the binaries in CVS, otherwise we will loose the possibility of doing diffs in CVS. Ah, when writing this another advantage of XXE come to my mind: a diff on OO files probably does not make much sense, as they store the XML unformatted. XXE indents and formats the XML nicely on save. Joerg
Re: [RT] The Cocoon Handbook
Nicola Ken Barozzi wrote: > Carlos Araya wrote: > > > I think that it needs to be a collaborative effort. There has to be a > > coordinator/prodder and collector of volunteers/editor but there has to be a > > collaborative effort as no one has expertise in all areas of Cocoon. > > We already did it, it was called the "documentation team". There was > (still is?) a mailing list for it. No. We tried it and then decided to rather discuss on the dev and users lists, leaving the docs list for just Wiki diffs. -- David Crossley
Re: [RT] The Cocoon Handbook
Carlos Araya wrote: > I think that it needs to be a collaborative effort. There has to be a > coordinator/prodder and collector of volunteers/editor but there has to be a > collaborative effort as no one has expertise in all areas of Cocoon. Definitely. We have the collaborators right here on the dev and users lists. Any one of us can be a prodder. Any one of us can lead by example. -- David Crossley
Re: [RT] The Cocoon Handbook
Joerg Heinicke wrote: > I can live with both OO and DocBook. While the latter one is really > straight forward for us, we will probably not really attract > documentors, even with some fancy editors like XXE as the usability is > not as good as with OO. But maybe that's only because the documentor > must have the document structure in mind. > > With OO it is much more difficult for us to process the results. The > documents are loose structured in the same way as HTML (no tree), but in > contrary to HTML there is at least support for requirements like > internal linking. A stylesheet processing those documents and adding the > structure will be really hard (massive Muenchian Grouping), but not > impossible of course. Therefore it's much easier for the documentor. I > would be interested how you did the templates, Sylvain, to see if this > solves problems of the post processing. > > The fact that OO files are not straight XML, but zipped XML, I would > ignore. It's easy for us to do zip/unzip automatically. We only must not > store the binaries in CVS, otherwise we will loose the possibility of > doing diffs in CVS. Ah, when writing this another advantage of XXE come > to my mind: a diff on OO files probably does not make much sense, as > they store the XML unformatted. XXE indents and formats the XML nicely > on save. So is this the process? ... When committers receive an update, then they unpack, view and save with XXE, then diffs are clearly seen, then commit the indented XML. -- David Crossley
Re: Cocoon Docs SVN Repository?
Nicola Ken Barozzi wrote: > To start off the new documentation effort, I'd like to use subversion > and html. > > This would give us the possibility of simply navigating the latest docs > in source control in an easy way, and given how well tortoiseSVN works > also to make it easier for doc writers. > > Is it ok if I ask infrastructure to create a cocoon/newdocs space in svn > so we can start working on it? Later on it can be moved under the final > cocoon destination with no effort (thanks to SVN :-) > > WDOT? Yes, i agree - use SVN and start with simple doc format (we can always transform that into some other type of source document later). Why not name the repository cocoon/docs ? -- David Crossley
Wiki status (Was: Cocoon Docs SVN Repository?)
Tony Collen wrote: > A few random questions: > > What is the status of the apache.org Wiki? Is it stable & usable? Not yet. What you see is the result of the latest test conversion. Upayavira asked for comments and there was not much reply, so lets assume that we are ready to do the final conversion. http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108583779606493 Gianugo suggested this upcoming FirstFriday (July 2) would be good to do a big group effort. We would do the conversion as the first thing, then do do a lot of editing and cleanup, set up the front matter, etc. > We could start fleshing out docs stuff over there. Use the current Wiki at cocoondev until then. > Should we have a cocoon-docs subwiki, or should we just consider > the whole thing the docs? What would be the benefit of a subwiki? > Should we be coordinating all this on -docs? See other mail today. We decided to keep the discussion on dev and users so that everyone is involved, not just a small band of overworked enthusiasts. -- David Crossley
Outdated infor about Cocoon in main apache site
Hi: I noted the info in main apache website about cocoon is outdated: http://www.apache.org/foundation/projects.html Best Regards, Antonio Gallardo
Re: Outdated infor about Cocoon in main apache site
Antonio Gallardo wrote: > I noted the info in main apache website about cocoon is outdated: > > http://www.apache.org/foundation/projects.html I recently updated the left-hand panel to give a better mouse-over tip. In response to your observation i added to the "site" CVS today: http://cvs.apache.org/viewcvs.cgi/site/xdocs/foundation/projects.xml To the top panel, added a concise phrase based on the top of our home page. Changed the description to that from Cocoon 2.1 index.html (Why isn't that on the Cocoon homepage?) I used only the first two paragraphs - was tempted to add the fifth para. However, that loses some important phrases from the old description: * "Designed for performance and scalability around pipelined SAX processing" * "centralized configuration system and sophisticated caching" We should try to merge those back again. BTW, anyone can send patches for the top-level main website via the Infrastructure Jira issues tracker. -- David Crossley
