Re: [proposal] move stuff from scratchpad into the trunk

FlowVelocityGenerator to replace VelocityGenerator Stefano Mazzocchi wrote: Here is what I propose to move: 1) ImageReader 2) Paginator 3) JXTemplate* anything else?

RE: Customization

I am trying to set a session variable to the value of a match variable (the customization name) and I am finding some difficulties: 1. There's no way to set a session variable from the sitemap. So I use XSP instead of a raw XHTML to set the variable there. I now need to pass a parameter to the

cvs commit: cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/impl DefaultLinkService.java

cziegeler2003/05/28 06:47:30 Modified:src/blocks/portal/java/org/apache/cocoon/portal/event/aspect/impl FrameEventAspect.java RequestParameterEventAspect.java src/blocks/portal/java/org/apache/cocoon/portal/coplet/adapter

Re: [proposal] move stuff from scratchpad into the trunk

Vadim Gritsenko wrote: Christopher Oliver wrote: FlowVelocityGenerator to replace VelocityGenerator -1 to replacing: FlowVelocityGenerator introduces dependencies on org.apache.commons.jxpath and org.mozilla.javascript which where missing in original VelocityGenerator. Why is that a

AW: Customization

hi fernando, assuming the snippet is from your actual sitemap; put that map:parameter inside the map:generate ;-) -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Mato Mira, Fernando Gesendet: Mittwoch, 28. Mai 2003 15:38 An: '[EMAIL

Re: [proposal] move stuff from scratchpad into the trunk

Christopher Oliver wrote: Vadim Gritsenko wrote: Christopher Oliver wrote: FlowVelocityGenerator to replace VelocityGenerator -1 to replacing: FlowVelocityGenerator introduces dependencies on org.apache.commons.jxpath and org.mozilla.javascript Sorry, org.mozilla.javascript is not a

Re: [proposal] move stuff from scratchpad into the trunk

Vadim Gritsenko wrote: Christopher Oliver wrote: Vadim Gritsenko wrote: Christopher Oliver wrote: FlowVelocityGenerator to replace VelocityGenerator -1 to replacing: FlowVelocityGenerator introduces dependencies on org.apache.commons.jxpath and org.mozilla.javascript Sorry,

FW: [xml-dev] Does SAX make sense?

The following came up on xml-dev. It's relevant to the discussions we've had in the past on SAX parsing alternatives (and somewhat academically interesting as well :-) In particular, note the performance comparisons with Xalan... Peter Hunsberger -Original Message- From: Patrick

Re: [proposal] move stuff from scratchpad into the trunk

Christopher Oliver wrote: Vadim Gritsenko wrote: ... First we are creating blocks for more modular design and the next thing is we are coupling everything back into monolith. I feel that's not the right way to go. We've got more than 5Mb worth of optional JARs (not counting blocks' libs) and

Re: Customization (ResourceSelectorAction?)

At 04:56 AM 5/28/2003, you wrote: Le Mercredi, 28 mai 2003, à 09:28 Europe/Zurich, Mato Mira, Fernando a écrit : ...There is a fallback mechanism whereby when the framework looks for some page foo the following search will be performed (say the user has Spanish in his preferences):

Re: Customization (ResourceSelectorAction?)

Le Mercredi, 28 mai 2003, à 13:37 Europe/Zurich, Geoff Howard a écrit : ...What about the chain input module? Is is certainly similar in concept to what I suggest, but how would you test for existence of files/resources dynamically with this module? -Bertrand

DO NOT REPLY [Bug 20308] New: - Stylesheet includes not working with XSLTC

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20308. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.

How to access sourceResolver in configure() method in action

Hello! I am using own ConfigurableComposerAction and I have problem with loading configuration from external file (from filesystem). In act() method, I would use SourceResolver from parameter passed to this method, but in configure() method I do not know where should I get the sourceresolver

DO NOT REPLY [Bug 16218] - IOException stream closed when cocoon redirects

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16218. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.

DO NOT REPLY [Bug 16218] - IOException stream closed when cocoon redirects

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16218. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.

DO NOT REPLY [Bug 16218] - IOException stream closed when cocoon redirects

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16218. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.

Re: XPathDirectoryGenerator

Torsten Knodt wrote: Hello, I'm currently working on my patchset of the week ;). One part is a modularized DirectoryGenerator. The only what is currently not included is the XPathDirectoryGenerator. As it can simply be simulated by XInclude, why having the code doubled? Or have I understood

RE: XPathDirectoryGenerator

Torsten Knodt wrote: Hello, I'm currently working on my patchset of the week ;). One part is a modularized DirectoryGenerator. The only what is currently not included is the XPathDirectoryGenerator. As it can simply be simulated by XInclude, why having the code doubled? Or have I

forrest not building current Cocoon docs

With current head cvs of both Cocoon-2.1 and Forrest i cannot build Cocoon docs. Does anyone else have these troubles or know what they mean? I also tried the stable tagged Forrest, but different error. * [0] - [broken page] index.htmlnull -

Re: Overloaded pipeline elements (Was Re: [RT] FOM)

Christian Haul wrote: On 28.May.2003 -- 12:51 PM, Marc Portier wrote: Christian Haul wrote: map:transformers map:transformer logger=sitemap.transformer.encodeURL name=encodeURL src=org.apache.cocoon.transformation.EncodeURLTransformer/

DO NOT REPLY [Bug 17771] - [PATCH] new logging category never set when using log logicsheet

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17771. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.

cvs commit: cocoon-2.1/src/webapp sitemap.xmap

crossley2003/05/29 02:46:24 Modified:src/webapp sitemap.xmap Log: Polish the explanatory text. Revision ChangesPath 1.19 +12 -11cocoon-2.1/src/webapp/sitemap.xmap Index: sitemap.xmap ===

Re: XPathDirectoryGenerator

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conal Tuohy wrote: transformer. So this would effectively mimic XPathDirectoryGenerator. But I think a single XPathDirectoryGenerator would be a lot simpler, and worth having. Because there are really people using it, I have put support in my

Re: FOP/HSSFSerializer's and non-english characters

On Thu, 29 May 2003 10:24:52 +0200 Maciek Kaminski [EMAIL PROTECTED] wrote: Yury Mikhienko wrote: Hi all! Cocoon's FOP/HSSFSerializer still does not support non-english characters, can I solve this problem? What can I do for this? Thanks for any advise. For HSSFSerializer see:

cvs commit: cocoon-2.1/src/documentation sitemap.xmap

jefft 2003/05/29 04:49:32 Modified:src/documentation sitemap.xmap Log: Upgrade to M2 syntax, used in CVS Forrest Revision ChangesPath 1.7 +100 -69 cocoon-2.1/src/documentation/sitemap.xmap Index: sitemap.xmap

Re: forrest not building current Cocoon docs

On Thu, May 29, 2003 at 06:00:39PM +1000, David Crossley wrote: With current head cvs of both Cocoon-2.1 and Forrest i cannot build Cocoon docs. Does anyone else have these troubles or know what they mean? I also tried the stable tagged Forrest, but different error.