[Woody] Datatypes revisited

Hi: I found another problem with binding: Woody current support is for java.util.Date OJB support is for java.sql.Date: http://db.apache.org/ojb/jdbc-types.html Problem here is we cannot make "direct" binding because of a cast class expception if we try to insert using OJB an Object java.util.D

Re: SAX done better?

Davanum Srinivas wrote: Hey, nice to see you here again, Dims! Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the op

Re: SAX done better?

FYI, threads on xerces-j-dev: http://news.gmane.org/onethread.php?group=gmane.text.xml.xerces-j.devel&root=%3C3F80F438.2060500%40apache.org%3E http://news.gmane.org/onethread.php?group=gmane.text.xml.xerces-j.devel&root=%3COFF6864861.CC02E004-ON85256DAB.006F7AF0%40ca.ibm.com%3E --- Marc Portier <

SAX done better?

Hi all, just been reading up on the new StAX API (http://jcp.org/en/jsr/detail?id=173) can't help being (a bit) enthousiastic, looks to me like an important step into the direction of efficient parsing of XML (seems to be more valuable then just a symbiosis of the existing pull parsing approac

Re: Revised ResourceLoadAction posted...

Vadim Gritsenko wrote: > Joerg Heinicke wrote: >> On 12.11.2003 23:26, Vadim Gritsenko wrote: >>> Had anybody considered writing some dom:/ pseudo protocol to >>> save/retrieve DOM fragments to/from request / session / application context? >> We have a Read/WriteDomSessionTransformer (for which A

XSP with multiple logicsheet compilation errors

Sorry for the cross-posting; I wasn't sure who would best be able to answer. We are using C2.0.3 on Tomcat 4.1. If it is relevant, the problem most frequently happens on our servers which are Solaris 8, Apache 1.3.x, mod_jk. We keep having a problem occasionally in which logicsheets are not

Re: [d'oh!] java APIs are not powerful enough to handle the XML spec!!

Stefano Mazzocchi wrote: The day somebody asks you why java needs to be replaced, one answer will be 'it only supports 16-bits chars'. laughable as it might seem, it's true. yes, people, a Unicode char is not 16 bit (as I always though!) but 32!! This is a misconception. Unicode is an odd mixture

Re: End of code freeze

Carsten Ziegeler wrote: The release is built, cvs tagged and the files are currently uploading. I will send the release mail tomorrow to give the mirrors some time. So, this is the end of the code freeze. Change at will. Cool job, thanks! -- Giacomo Pati Otego AG, Switzerland - http://www.otego.

Re: Bastardized URL protocol

Stefano Mazzocchi wrote: Sigh. I'm not going to force you guys not to make the same mistake again. It seems I am the only one who doesn't like it, even though I strongly encourage at least stripping out *one* of the forward slashes so that a relative URI has no forward slashes at the beginning

Re: Bastardized URL protocol

On 13 Nov 2003, at 11:35, Berin Loritsch wrote: Sylvain Wallez wrote: Carsten Ziegeler wrote: Berin Loritsch wrote: Just because we have one protocol that is messed up and we can't change it doesn't mean we should make the same mistakes. True. For the Context protocol, I highly recommend doin

Re: [d'oh!] java APIs are not powerful enough to handle the XML spec!!

Stefano Mazzocchi wrote: The day somebody asks you why java needs to be replaced, one answer will be 'it only supports 16-bits chars'. laughable as it might seem, it's true. yes, people, a Unicode char is not 16 bit (as I always though!) but 32!! And even the XML specification says so. Char :

Re: [vote] forbidding flowscripts with no sendpage redirects (was Re: Saving pipeline output to a temp file...)

On 13 Nov 2003, at 00:20, Andrzej Jan Taramina wrote: Ugo suggested: function dumpData() { dumpUserData(); dumpOrderData(); dumpNewsItems(); cocoon.sendPage("view"); } The main problem I have with this approach is that without looking at the script cod

Re: Serializers and SitemapModelComponent

Borges Charles wrote: Hi, Quoting the SitemapModelComponent interface javadoc: "This interface marks a component as a sitemap component that is used in the processing phase, like a generator, a transformer, a SERIALIZER or a reader" But the Serializer interface doesn't extends the SiteMapModel

MountTableMatcher

I all, I wrote a little goodie that hopefully will be very helpful to all of us: the MountTableMatcher. This is a matcher that manages a "mount table", allowing to add subsitemaps to a Cocoon application without modifying the main sitemap. This is especially useful for two purposes: - to moun

[d'oh!] java APIs are not powerful enough to handle the XML spec!!

The day somebody asks you why java needs to be replaced, one answer will be 'it only supports 16-bits chars'. laughable as it might seem, it's true. yes, people, a Unicode char is not 16 bit (as I always though!) but 32!! And even the XML specification says so. Char ::=  #x9 | #xA | #xD | [#x2

Serializers and SitemapModelComponent

Hi, Quoting the SitemapModelComponent interface javadoc: "This interface marks a component as a sitemap component that is used in the processing phase, like a generator, a transformer, a SERIALIZER or a reader" But the Serializer interface doesn't extends the SiteMapModelComponent interface...

RE: Bastardized URL protocol

> -Original Message- > From: Sylvain Wallez [mailto:[EMAIL PROTECTED] > Sent: donderdag 13 november 2003 16:31 > To: [EMAIL PROTECTED] > Subject: Re: Bastardized URL protocol > > > Carsten Ziegeler wrote: > > >Berin Loritsch wrote: > > > > > >>Just because we have one protocol that

Re: Bastardized URL protocol

Sylvain Wallez wrote: Carsten Ziegeler wrote: Berin Loritsch wrote: Just because we have one protocol that is messed up and we can't change it doesn't mean we should make the same mistakes. True. For the Context protocol, I highly recommend doing something other than the one slash vs.

Re: Bastardized URL protocol

Carsten Ziegeler wrote: Berin Loritsch wrote: Just because we have one protocol that is messed up and we can't change it doesn't mean we should make the same mistakes. True. For the Context protocol, I highly recommend doing something other than the one slash vs. two approach used for

Woody upload widget

Hi all, Now that the code freeze is over, I can commit things that have been waiting on my PC. This starts with a woody upload editor. Docs are at http://wiki.cocoondev.org/Wiki.jsp?page=WoodyWidgetReference#ref-WoodyWidgetReference-11 and a new sample has been added. Enjoy! Sylvain -- Sylv

Re: Bastardized URL protocol

Carsten Ziegeler wrote: Berin Loritsch wrote: Just because we have one protocol that is messed up and we can't change it doesn't mean we should make the same mistakes. True. For the Context protocol, I highly recommend doing something other than the one slash vs. two approach used for the "cocoo

RE: Bastardized URL protocol

Berin Loritsch wrote: > Just because we have one protocol that is messed up and we can't change it > doesn't mean we should make the same mistakes. > True. > For the Context protocol, I highly recommend doing something other than > the one slash vs. two approach used for the "cocoon" protocol. > >

Re: Bastardized URL protocol

Vadim Gritsenko wrote: Stefano Mazzocchi wrote: The only potential solution I see is something like I think that would not be correct usage of the xml:base... Correct usage would be something like: Wouldn't it be much more common to do something like this:

Re: Bastardized URL protocol

Stefano Mazzocchi wrote: On 12 Nov 2003, at 17:18, Berin Loritsch wrote: Stefano Mazzocchi wrote: Variable scoping aside, do you have any suggestion on how to solve the protocol issue? -- Stefano, who reached a point where rants look like a very inefficient way of solving problems As I menti

Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/xml SaxBuffer.java

On Thu, 2003-11-13 at 14:27, Vadim Gritsenko wrote: > [EMAIL PROTECTED] wrote: > > > * On the other hand, its data structure is more complex then a simple byte array, > > * making XMLByteStreamCompiler better in case the recorded SAX should be stored > > long-term. > > > > > ... > > >

Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/xml SaxBuffer.java

[EMAIL PROTECTED] wrote: * On the other hand, its data structure is more complex then a simple byte array, * making XMLByteStreamCompiler better in case the recorded SAX should be stored long-term. ... final class PI implements SaxBit { You may want to make those inner classes stat

Re: whitespace cleanup and efficiency drive

David Crossley wrote: Joerg Heinicke wrote: The result of this thread: let's care only about white spaces. So now we need a policy. Here is my proposal: For all text files - Replace all tabs with spaces. - No trailing whitespace. - No M$-DOS line endings. - Newline at end-of-file. - Singl

Re: End of code freeze

Sylvain Wallez dijo: > Carsten Ziegeler wrote: > >>The release is built, cvs tagged and the files are currently >>uploading. I will send the release mail tomorrow to give >>the mirrors some time. >> >> > > Thanks Carsten, and congrats to all for yet-another-release of the > mighty Cocoon ;-) > >>So

Re: End of code freeze

Carsten Ziegeler wrote: The release is built, cvs tagged and the files are currently uploading. I will send the release mail tomorrow to give the mirrors some time. Thanks Carsten, and congrats to all for yet-another-release of the mighty Cocoon ;-) So, this is the end of the code freeze. Cha

DO NOT REPLY [Bug 24681] New: - xml2html adding too many margins

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: Bastardized URL protocol

On 12 Nov 2003, at 17:18, Berin Loritsch wrote: Stefano Mazzocchi wrote: Variable scoping aside, do you have any suggestion on how to solve the protocol issue? -- Stefano, who reached a point where rants look like a very inefficient way of solving problems As I mentioned in another email, levera

Re: cvs commit: cocoon-2.1 blocks.properties

[EMAIL PROTECTED] wrote: cziegeler2003/11/13 02:18:28 Modified:.blocks.properties Log: Exclude JMS for the release; otherwise Cocoon doesn't compile with 1.3 :( We have to find a better solution for the next version *All* blocks must be able to be included by default and sh

Re: End of code freeze

Carsten Ziegeler dijo: > The release is built, cvs tagged and the files are currently > uploading. I will send the release mail tomorrow to give > the mirrors some time. > > So, this is the end of the code freeze. Change at will. Thanks and congrats! :-D Best Regards, Antonio Gallardo

End of code freeze

The release is built, cvs tagged and the files are currently uploading. I will send the release mail tomorrow to give the mirrors some time. So, this is the end of the code freeze. Change at will. Carsten

Cocoon dinner in Paris?

Hi all, The 26th and 27th of november, the "Intégration XML & Web Services" exhibtion will take place in Paris [1]. My company will have a booth there demonstrating a lot of Cocoon-based projects, and I will give a presentation on Cocoon [2]. As a number of french Cocoon addicts are likely to

DO NOT REPLY [Bug 24647] - content-length in ResourceReader

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: [vote] forbidding flowscripts with no sendpage redirects (was Re: Saving pipeline output to a temp file...)

Reinhard Poetz wrote: I don't like it that we blur the Flowscript concept to achieve things that can already be done today nearly in the same way some of you propose. In the long run I fear that nobody knows what the Cocoon Control flow is about and everybody talks about different things. I think t

Re: [RT] ComponentizedProcessor (was RE: Migrating TreeProcessor to Fortress)

Stefano Mazzocchi wrote: ... The benefit of this community is that nobody is really attached to his/her code. We value challenges and wild thinking more than we value self pride. Hey, don't touch my bugs! Oops I meant code ;-) -- Nicola Ken Barozzi [EMAIL PROTECTED]

Re: cvs commit: cocoon-2.1 gump.xml blocks.properties

On 13.11.2003 06:42, [EMAIL PROTECTED] wrote: crossley2003/11/12 21:42:50 Modified:.gump.xml blocks.properties Log: Petsore depends on velocity and woody. Another one I missed. Thanks. Joerg

RE: [vote] forbidding flowscripts with no sendpage redirects (was Re: Saving pipeline output to a temp file...)

From: Andrzej Jan Taramina > Ugo suggested: > > > > > > > > > > > > > > > > > > > > > > > function dumpData() { > >dumpUserData(); > >dumpOrderData(); > >dumpNewsItems(); > >cocoon.sendPage("view"); > > } > > > > The main problem I have with t

Re: GT 2003 talks: low-bandwidth ogg audio files are online

Bertrand Delacretaz wrote: > > IIUC this means they will be available on the mirrors soon - please use > the mirrors for download. http://cocoon.apache.org/mirror.cgi Thanks, it is nice to hear you all. --David

RE: Building docs fails

Carsten Ziegeler wrote: > I get the following using latest CVS of forrest. I will try 0.5.1 now. It looks like the problem with the CLI getting confused about its context directory. Yes 0.5.1 works. I tried it a few minutes ago and added to http://wiki.cocoondev.org/Wiki.jsp?page=CocoonWebsiteUpd

RE: Building docs fails

I get the following using latest CVS of forrest. I will try 0.5.1 now. Index optimized! - Total milliseconds 7441 - Webapp generated in build/webapp-site To run in Tomcat, add this to the config file (usu. server.xml):

Re: whitespace cleanup and efficiency drive

Joerg Heinicke wrote: > The result of this thread: let's care only about white spaces. So now we need a policy. Here is my proposal: For all text files - Replace all tabs with spaces. - No trailing whitespace. - No M$-DOS line endings. - Newline at end-of-file. - Single whitespace between words.