RE: Cocoon book reviewers wanted

Hi Michael, good question. The book covers from the absolute beginner to the the guru-developer - and I do not know which chapters they will be sending out. Send me a personal email and I will put you on the list (if you are interested). Matthew -Original Message- From: Michael Homei

RE: Cocoon book reviewers wanted

Hi Matthew, What kind of readers do you expect? Skills, level etc? Michael > -Original Message- > From: Matthew Langham [mailto:[EMAIL PROTECTED]] > Sent: woensdag 22 mei 2002 8:36 > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Cocoon book reviewers wanted > > > Hi, > > togeth

Cocoon book reviewers wanted

Hi, together with our publisher (www.newriders.com), we are looking for people interested in reviewing chapters from our book. Hopefully you will have something positive to say and then your quote may be used in the book or to promote it. If you would be interested then please send me an email.

Explicit setting of classic compiler for building

Hi, do we really need this property: in our build file? Without this the default compiler is used. Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-cocoon2/src/webapp/samples/xmlform README.txt

ivelin 02/05/21 20:56:05 Modified:src/webapp/samples/xmlform README.txt Log: update Revision ChangesPath 1.2 +13 -6 xml-cocoon2/src/webapp/samples/xmlform/README.txt Index: README.txt ===

Re: Flow and XMLForm [LONG]

Both of you have good points, guys. I am not sure what is the answer to these tough questions. And I certainly don't mind any further extensions that will benefit Cocoon users. I can only say that the next thing I'll be working on is to show how XMLForm can be used to write REST oriented Web S

Fw: [Workflow] Is this project still active?

For those that are not on the commons list, this may be interesting. Especially for the Schecoon fans. - Original Message - From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, May 21, 2002 8:49 PM Subject: Re: [Workflo

Fw: [Workflow] Is this project still active?

FYI, Jakarta Workflow seems to be fading. Does this mean that Cocoon sitemap is the new game in town? Ovidiu, probably this is a good chance for you to promote Schecoon across Apache projects. See below. Cheers, Ivelin - Original Message - From: "Warner Onstine" <[EMAIL PROTECTED

Fw: XSLTC and Cocoon

More positive response from the XSLTC team ! - Original Message - From: "David Hofert" <[EMAIL PROTECTED]> To: "Ivelin Ivanov" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, May 21, 2002 7:02 AM Subject: Re: XSLTC and Cocoon > Hi Ivelin - > > I'm glad that my team has bee

Re: Flow and XMLForm [LONG]

Hello, > From: "Ovidiu Predescu" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Monday, May 20, 2002 10:03 PM > Subject: Re: Flow and XMLForm > JavaScript client validation improves the user experience quite a bit, > so I think a validation solution should gene

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/language/markup/xsp/java esql.xsl

haul02/05/21 12:37:44 Modified:src/java/org/apache/cocoon/components/language/markup/xsp/java esql.xsl Log: forgotten switch statement broke no-results. Patch thanks to Tim Myers. Revision ChangesPath 1.24 +4 -2 xml-cocoon2/src/java

RE: [RT]: Calculating the cache key

I just read a post on the users list from someone wishing that file generator's cache validity could check dependencies of xml/xslt files which use the document() function. This is obviously unfeasible in the current structure, but may be workable if the file generator could store dependencies in

RE: [RT]: Calculating the cache key

I like all that -- assume it would involve fairly invasive restructuring of the whole pipeline process, but need to go read up on the prior discussion you mention. Seems like from a performance standpoint, the per-pipeline setup is best: non-cached matches don't need to waste time checking a ca

Re: XSLTC and Cocoon

On Tuesday 21 May 2002 18:13, Stefano Mazzocchi wrote: > Tom, > > first of all, thanks much for helping us with this. It is *very* > appreciated. > > Tom Amiro wrote: > > Hi, > > > > After modifying ./documentation/stylesheets/book2menu.xsl so XSLTC > > could compile it, I got to the next problem,

Re: XSLTC and Cocoon

Tom, first of all, thanks much for helping us with this. It is *very* appreciated. Tom Amiro wrote: > Hi, > > After modifying ./documentation/stylesheets/book2menu.xsl so XSLTC > could compile it, I got to the next problem, which doesn't appear > to be XSLTC related. Ok, let's see. > Afte

Re: SUMMARY [ was Re: [LAW] Quick Lesson in Copyright Law (was RE:copyright for docs [was: Re: [Bugs] URLSource])

First of all, I'm not a lawyer and I know everything I know about these issues becaues I've been watching legal battles over [EMAIL PROTECTED] and [EMAIL PROTECTED] which are, unfortunately but for good reasons, closed lists. I'll try to shed some light on this. Diana Shannon wrote: > Here's

Re: [RT]: Calculating the cache key

Geoff Howard wrote: >The performance of key comparison is especially important for high traffic >sites (like ours). An idea I've had to decrease this importance is: > >An *option* to have the pipeline do asynchron cache validation - if a cached >item exists, use it *then* check it's validity (or

[GUMP] Build Failure - xml-cocoon2

[echo] -- [echo] Apache Cocoon 20020521 [1999-2002] [echo] -- [echo] Building with Apache Ant version 1.6alpha compiled on May 21 2002 [echo] using build file

RE: [RT]: Calculating the cache key

I like that idea... > -- > From: Geoff Howard[SMTP:[EMAIL PROTECTED]] > Reply To: [EMAIL PROTECTED] > Sent: Tuesday, May 21, 2002 11:10 AM > To: '[EMAIL PROTECTED]' > Subject: RE: [RT]: Calculating the cache key > > The performance of key comparison is especiall

RE: Problems with Saxon (6.5.2) and resolver (Cocoon 2.0.2)

Another observation I forgot: it appears to be very very important to clear out your cache (Tomcat/work) directory after switching jars and before restarting, otherwise you get null pointer exceptions. Probably obvious to a lot of people but it wasn't to me > -Original Message- > Fr

Problems with Saxon (6.5.2) and resolver (Cocoon 2.0.2)

I've been struggling with getting Saxon 6.5.2 and Cocoon 2.0.2 working together for a couple of days now Here's what I did and what I found: 1. I replaced xalan-2.3.1 with saxon.jar. 2. I grabbed v1.9 of xsp.xsl (http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/java/org/apache/cocoo n/compo

RE: SourceFactory for content managment

That was me asking about the CVS Source Factory. I've been delving into the CVS code in Netbeans, and it actually looks pretty straight forward to do, but I have limited opporutnities to work on it, so it has been ( and will be ) slow going... > -- > From: Nicola Ken Barozzi[SMTP:

RE: XSLTC and Cocoon

> From: Stephen Ng [mailto:[EMAIL PROTECTED]] > > Ivelin, > > Thank you for spearheading this! > > I am currently moving my code to Saxon to improve performance; it's > quite a bit more painful than I thought--will post my observations > shortly. That's very interesting - my observations are q

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/webapps/session/connector ResourceConnector.java ResourceConnectorImpl.java

cziegeler02/05/21 07:14:51 Modified:src/java/org/apache/cocoon/webapps/session/connector ResourceConnector.java ResourceConnectorImpl.java Log: Removing some methods, I hope to get rid of the resource connector as soon as possible. Revision Changes

RE: [RT]: Calculating the cache key

Berin Loritsch wrote: > > > > > > > > > 'h'*31^(39-1) + 't'*31^(39-2) + 'l' > > > > > > I'll let you do the math yourself. > > > > Yes, but what if my strings are, let's say 1000 characters > > long? And looking at the code for example in the xslt > > transformer or some other places

RE: [RT]: Calculating the cache key

-Original Message- From: Berin Loritsch [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 21, 2002 9:34 AM To: [EMAIL PROTECTED] Subject: RE: [RT]: Calculating the cache key > Let's say we have the FileGenerator (most likely to have the > highest number of unique resources). True for stat

RE: XSLTC and Cocoon

Ivelin, Thank you for spearheading this! I am currently moving my code to Saxon to improve performance; it's quite a bit more painful than I thought--will post my observations shortly. Point being XSLT performance is really important as you have been saying, and thanks for getting this moving.

Re: XSLTC and Cocoon

Ivelin Ivanov wrote: >Folks, > > >The XSLTC team is trying to resolve the issues preventing XSLTC from being >used in Cocoon. > >Please see below the problem they got into and try to help, if you can. > > > >BTW, Tom, > >I think I can safely suggest that you post further issues related to Cocoon

RE: [RT]: Calculating the cache key

> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] > > Berin Loritsch wrote: > > > > 'h'*31^(39-1) + 't'*31^(39-2) + 'l' > > > > I'll let you do the math yourself. > > Yes, but what if my strings are, let's say 1000 characters > long? And looking at the code for example in the xslt

Re: XSLTC and Cocoon

Folks, The XSLTC team is trying to resolve the issues preventing XSLTC from being used in Cocoon. Please see below the problem they got into and try to help, if you can. BTW, Tom, I think I can safely suggest that you post further issues related to Cocoon directly to the dev list. It is of

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/webapps/session/connector Resource.java

cziegeler02/05/21 06:19:20 Modified:src/java/org/apache/cocoon/webapps/session/connector Resource.java Log: Fixing resource detection Revision ChangesPath 1.4 +10 -4 xml-cocoon2/src/java/org/apache/cocoon/webapps/session/connector/Resou

RE: [RT]: Calculating the cache key

Berin Loritsch wrote: > > > > I'm wondering about the whole hash algorithm. Concatenating > strings can get expensive, especially if it is done in multiple > sections mutliple times. The fact is that hash values as a long > provide a virtually limitless number of possibilities for cache > va

RE: [RT]: Calculating the cache key

> From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > > Perhaps something along these lines: > > s[0]%n*2^(32/n) + s[1]%n*s^(32/n) .. s[n-1]%n*s^(32/n) > oops. I meant: s[0]%n*2^(32/n) + s[1]%n*2^(32/n) .. s[n-1]%n*2^(32/n) ^+---^

RE: [RT]: Calculating the cache key

> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] > > Hi, > > with the new source resolving (from excalibur) we can > implement a better caching mechanism (I mentioned this > several times in the last weeks). > > I'm just wondering, how the cache key should be generated. > > The current s

[PATCH] RequestParamAction. Can now put sitemap parameters to request attribute

Hi, I was experimenting with C2:s cinclude system and found out that original sitemap parameters do not exist when cincluded content is called I'm wanted to use url itself to describe user and I needed to forward that info on Python scripts. and in data.

Re: Flow and XMLForm

On Tue, 21 May 2002 00:12:16 -0500, "Ivelin Ivanov" <[EMAIL PROTECTED]> wrote: > - Original Message - > From: "Ovidiu Predescu" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Monday, May 20, 2002 10:03 PM > Subject: Re: Flow and XMLForm > > > > So there ar

Re: Flow and XMLForm

- Original Message - From: "Ovidiu Predescu" <[EMAIL PROTECTED]> To: "Ivelin Ivanov" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, May 21, 2002 1:04 AM Subject: Re: Flow and XMLForm > > Just a note in regard to client/server side validation. > > New generation browsers suppo

DO NOT REPLY [Bug 9267] - SourceFactory for jakarta slide

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

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/transformation I18nTransformer.java

cziegeler02/05/21 05:24:57 Modified:src/java/org/apache/cocoon/components/flow AbstractInterpreter.java src/java/org/apache/cocoon/components/request/multipart FilePart.java FilePartArray.java FilePartFile.java

RE: Crimson parser and cocoon202

As long as the current Crimson parser is JAXP 1.1 compliant, and supports namespaces as the spec states then there is no problem. Crimson _used_ to violate the spec on namespace handling, but I *think* it has since been fixed. If something bites you, it will most likely be in this area. > -

Re: SourceFactory for content managment

On Tue, 21 May 2002, Nicola Ken Barozzi wrote: > From: "Stephan Michels" <[EMAIL PROTECTED]> > > > Hi, > > > > last week there was a liitle discussion about a SourceFactory for > > CVS repositories. I tried to find a CVS libary to implement such a > > SourceFactory, but I doesn't had luck. All

DO NOT REPLY [Bug 9267] - SourceFactory for jakarta slide

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

DO NOT REPLY [Bug 9267] - SourceFactory for jakarta slide

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

[RT]: Calculating the cache key

Hi, with the new source resolving (from excalibur) we can implement a better caching mechanism (I mentioned this several times in the last weeks). I'm just wondering, how the cache key should be generated. The current solution (Interface Cacheable) uses a long which is in 99,9% a hash value of

DO NOT REPLY [Bug 9267] - SourceFactory for jakarta slide

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

DO NOT REPLY [Bug 9267] New: - SourceFactory for jakarta slide

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

Re: SourceFactory for content managment

Great!! I hope one of the commiters applies this patch ASAP. Slide together with cocoon is IMHO a "killer" app. Cocoon as a frontend. Slide as a backend with multiple store implementations and webdav for interacting with it from filesystems and clients. Great work! /Regards Mats - Original

RE: SourceWriterTransformer problems

You also have to update the cocoon.xconf in order to register the source factory for the file: protocol. I just changed the implementation of the context: protocol, it should now be writeable (if translated to file:) as well. Carsten -Original Message- From: Jeremy Aston [mailto:[EMAIL P

cvs commit: xml-cocoon2/src/webapp/WEB-INF cocoon.xconf

cziegeler02/05/21 03:16:20 Modified:src/java/org/apache/cocoon/components ExtendedComponentSelector.java src/java/org/apache/cocoon/components/pipeline AbstractProcessingPipeline.java ProcessingPipeli

Re: SourceFactory for content managment

From: "Stephan Michels" <[EMAIL PROTECTED]> > Hi, > > last week there was a liitle discussion about a SourceFactory for > CVS repositories. I tried to find a CVS libary to implement such a > SourceFactory, but I doesn't had luck. All libaries work over > local stored files. Not netbeans' AFAIK.

SourceFactory for content managment

Hi, last week there was a liitle discussion about a SourceFactory for CVS repositories. I tried to find a CVS libary to implement such a SourceFactory, but I doesn't had luck. All libaries work over local stored files. But on my way, I found the jakarta slide project. It seems to me very interes

DO NOT REPLY [Bug 9105] - [PATCH] Fixed Bug in SQLTransformer when doing INSERT or UPDATE

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

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/transformation SQLTransformer.java

cziegeler02/05/21 02:41:54 Modified:src/java/org/apache/cocoon/transformation SQLTransformer.java Log: Fixed Bug in SQLTransformer when doing INSERT or UPDATE PR: 9105 Submitted by: [EMAIL PROTECTED] (Jens Lorenz) Revision ChangesPath 1.12

Crimson parser and cocoon202

Hello everyone, Does anyone know a reason if cocoon202 will work with the crimson parser? I have tried it and it seems to work. Is something bad going to come and bite me when all seems ok? (I am having various jboss problems which makes it necessary for me to use crimson rather than xerces.)

Re: [C2.1] Moving scratchpad goodies to main trunk

From: "Jeremy Quinn" <[EMAIL PROTECTED]> > On Saturday, May 18, 2002, at 03:52 PM, Stefano Mazzocchi wrote: > > Konstantin Piroumian wrote: > >> > >> Hi all! > >> > >> Isn't it time to move things from scratchpad to the main trunk? > >> Here is the list of what I would personally like to see in th

Re: [C2.1] Moving scratchpad goodies to main trunk

From: "Jeremy Quinn" <[EMAIL PROTECTED]> > > On Saturday, May 18, 2002, at 03:52 PM, Stefano Mazzocchi wrote: > > > Konstantin Piroumian wrote: > >> > >> Hi all! > >> > >> Isn't it time to move things from scratchpad to the main trunk? > >> Here is the list of what I would personally like to see

Re: [C2.1] Moving scratchpad goodies to main trunk

On Saturday, May 18, 2002, at 03:52 PM, Stefano Mazzocchi wrote: > Konstantin Piroumian wrote: >> >> Hi all! >> >> Isn't it time to move things from scratchpad to the main trunk? >> Here is the list of what I would personally like to see in the >> main trunk: >> >> >> - Editor > If by t

cvs commit: xml-cocoon2/src/webapp sitemap.xmap

cziegeler02/05/21 01:29:36 Modified:src/java/org/apache/cocoon/components/source SourceUtil.java src/java/org/apache/cocoon/webapps/session session-tran.xmap src/java/org/apache/cocoon/xml/dom DOMStreamer.java src/webapp sitemap.xmap Added:

Re: [RT] Cocoon Exception Handling Infrastructure

From: "Torsten Curdt" <[EMAIL PROTECTED]> > > XSLT Transformer is obviously one of the most popular Cocoon components. > > As such it carries the extra burden of serving as example to people writing > > other components. > > > > In the sake of fairness, exception reporting is much friendlier in 2

Re: [RT] Cocoon Exception Handling Infrastructure

> XSLT Transformer is obviously one of the most popular Cocoon components. > As such it carries the extra burden of serving as example to people writing > other components. > > In the sake of fairness, exception reporting is much friendlier in 2.1 than > before. However much remains to be improved