Re: Linotype editing: browser requirements?

On 19/06/2003 5:03 Stefano Mazzocchi wrote: ??? there is no such line in linotype/flow.js. Whick flow.js have you modified? There is, now, and I introduced it in a vein attempt to overcome your hardwiring of the user properties file. I'll dive into it and check what I've done wrong - since I tes

cvs commit: cocoon-2.1/src/blocks/linotype/samples/stylesheets request2news.xslt

vgritsenko2003/06/18 21:20:34 Modified:src/blocks/linotype/samples/stylesheets request2news.xslt Log: Remove unused r and h (request and xhtml) namespaces from the resulting document Revision ChangesPath 1.2 +16 -9 cocoon-2.1/src/blocks/linotype/samples/stylesh

Re: [RT] [Cocoon 2.2] Stacktraces in context

on 6/18/03 4:39 PM Bart Guijt wrote: > Hi all, > > I am using Cocoon for almost a year now and if one thing bugs me, it is > this: if something fails to operate successfully, the Java stacktraces fail > most of the time to correctly show how the error occurred. Yeah, damn, don't tell me, this ha

Re: Linotype editing: browser requirements?

on 6/18/03 3:07 PM Roger I Martin PhD wrote: > was getting the following double cocoon for the path to > linotype.users.properties > > org.apache.avalon.framework.CascadingRuntimeException: "file:/C:/Program > Files/jakarta-tomcat-5/dist/webapps/cocoon/samples/linotype/flow.js", line > 10: uncaug

Re: Linotype editing: browser requirements?

on 6/18/03 3:56 AM Sylvain Wallez wrote: > Gianugo Rabellino wrote: > > > >>BTW, Stefano: Linotype *really* kicks ass. Problem is that from you we >>aren't expecting anything less, so this is why you are not getting all >>the kudos you deserve. :-) But it's really, really, really a good job!

Re: Linotype editing: browser requirements?

on 6/18/03 3:16 AM Ugo Cei wrote: > Gianugo Rabellino wrote: > >>>Anyway, I'm wondering why the multipart request. Is it because of >>>images? If it weren't for images, wouldn't it be better to POST a >>>text/xml body with all the necessary information, putting the "verb" >>>(save, delete, etc

Re: Linotype editing: browser requirements?

on 6/18/03 2:12 AM Ugo Cei wrote: > Stefano Mazzocchi wrote: > >>No, no need for that. It took me half an hour to figure that problem out >>myself and it's an indication of how generally badly designed is >>cocoon's handling of multipart-encoded POST requests. > > > Could it be useful to docume

Re: AbstractSAXTransformer logging (Re: cvs commit: ... AbstractSAXTransformer.java)

Carsten Ziegeler wrote: Jeff Turner wrote: I'm not too sure of this commit. The problem is that AbstractSAXTransformer's debug-level logging is so verbose that it swamps the debug logs of its children with stuff like this: DEBUG (/forrest/body-index.html): BEGIN endTransformingElement uri=, nam

Re: Hibernate sessions (was Re: [vote results] FOM)

On Wednesday, June 18, 2003, at 02:14 PM, Ugo Cei wrote: Jeremy Quinn wrote: Because (I just realised) the Session has to be thrown away if there is any kind of Hibernate Exception, I was beginning to realise the only way of handling that safely was to wrap each call to Hibernate with a new Ses

Re: [RFI] Garbage

On 18/6/03 22:17, "Peter Royal" <[EMAIL PROTECTED]> wrote: > On Wednesday, June 18, 2003, at 01:34 PM, Pier Fumagalli wrote: > >> Concise question, concise answer: >> >> Forget the XML syntax, use JXPath instead of JEXL for expressions... >> Like: >> >> >> #foreach $header in {request/headers}

Re: A proposal for a best practice project

Bertrand Delacretaz wrote: Le Lundi, 16 juin 2003, à 08:56 Europe/Zurich, Ross Gardler a écrit : ...Shall I keep the project discussions on this list, or should I start a project elsewhere (e.g. SF/Krysalis/CocoonDev) and report back to this list on significant events?... Discussing it here will

[RT] [Cocoon 2.2] Stacktraces in context

Hi all, I am using Cocoon for almost a year now and if one thing bugs me, it is this: if something fails to operate successfully, the Java stacktraces fail most of the time to correctly show how the error occurred. In Cocoon, we use sitemaps, XSL transformers, (additional) Java components and URI

Re: [RFI] Garbage

On Wednesday, June 18, 2003, at 01:34 PM, Pier Fumagalli wrote: Concise question, concise answer: Forget the XML syntax, use JXPath instead of JEXL for expressions... Like: #foreach $header in {request/headers} #if {starts-with($header/name, 'X-'} #else #end T

Re: Linotype editing: browser requirements?

was getting the following double cocoon for the path to linotype.users.properties org.apache.avalon.framework.CascadingRuntimeException: "file:/C:/Program Files/jakarta-tomcat-5/dist/webapps/cocoon/samples/linotype/flow.js", line 10: uncaught JavaScript exception: java.io.FileNotFoundException: C:

RE: Divorse Cocoon creation from CocoonServlet

> > At the moment, the CocoonBean isn't an Avalon > > component (and I want to see it being possible to use it > > outside an Avalon context), but should be possible to make it > > into a component. Your maillet (for example) could then get a > > CocoonBean from Avalon and use it to write to th

Re: Why does moving the portal-fw from samples break it? (PortalManager not found on 'save')

On Wed, 18 Jun 2003, Carsten Ziegeler wrote: > > -Original Message- > > From: Rob Johnston [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 17, 2003 8:11 PM > > To: [EMAIL PROTECTED] > > Subject: Why does moving the portal-fw from samples break it? > > (PortalManager not found on 'save')

JSR 173 - Streaming API for XML

I searched the archives but couldn't find any reference to this even though it seems familiar: http://jcp.org/en/jsr/detail?id=173 It seems a long time before it will be relevant, but it's certainly something that Cocoon could exploit. In particular for some kinds of Transformers and Seri

Re: [RFI] Garbage

"Peter Royal" <[EMAIL PROTECTED]> wrote: > On Tuesday, June 17, 2003, at 08:07 PM, Pier Fumagalli wrote: > >> The most peculiar one is that I always _hated_ the fact that Velocity >> output >> need to be passed through a parser _every_time_ the content is >> generated >> (Velocity is stream-based

Re: [RFI] Garbage

On Tuesday, June 17, 2003, at 08:07 PM, Pier Fumagalli wrote: The most peculiar one is that I always _hated_ the fact that Velocity output need to be passed through a parser _every_time_ the content is generated (Velocity is stream-based, not SAX-based), so what my little template does is that

RE: Divorse Cocoon creation from CocoonServlet

Hi Upayavira, Thanks for your reply. > Unico, > > Have you looked at the CocoonBean. As I see it it is intended > to provide a simple interface for interacting with Cocoon. I've seen it and was intending to use it too! :) > It > is largely used by the CLI to batch generate pages > statical

Re: Divorse Cocoon creation from CocoonServlet

Unico, Have you looked at the CocoonBean. As I see it it is intended to provide a simple interface for interacting with Cocoon. It is largely used by the CLI to batch generate pages statically, but has a method to generate a URI and pass the result to an output stream of your choosing (not sure

Re: TreeProcessor:BUG

Klaus Bertram wrote: Sylvain Wallez wrote: Klaus Bertram wrote: Hi Joerg yes I found it by debugging an action where the breakpoint was stoped twice. So I wrote a small test sidemap with an xsp side and database actions By request the map:aggregation match, an action in map:part add a row to

DO NOT REPLY [Bug 20869] - [PATCH] Make Cocoon running on IBM's SDK 1.4.1

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 20869] New: - [PATCH] Make Cocoon running on IBM's SDK 1.4.1

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: AbstractSAXTransformer logging (Re: cvs commit: ... AbstractSAXTransformer.java)

Yes, yes, remove this stuff! I'll know if the hooks are being called if I a) use the right namespace b) override the hooks methods. I'm sure these were helpful at one point, but now David Carsten Ziegeler wrote: Jeff Turner wrote: I'm not too sure of this commit. The problem

Re: Hibernate sessions (was Re: [vote results] FOM)

Jeremy Quinn wrote: Because (I just realised) the Session has to be thrown away if there is any kind of Hibernate Exception, I was beginning to realise the only way of handling that safely was to wrap each call to Hibernate with a new Session. Not every call to Hibernate but every HTTP request p

RE: AbstractSAXTransformer logging (Re: cvs commit: ... AbstractSAXTransformer.java)

Jeff Turner wrote: > > I'm not too sure of this commit. The problem is that > AbstractSAXTransformer's > debug-level logging is so verbose that it swamps the debug logs > of its children > with stuff like this: > > DEBUG (/forrest/body-index.html): BEGIN endTransformingElement > uri=, name=link,

Cocoon resource publishing

Hi everybody, As you all know, there are currently two ways that Cocoon resources are published: either over http or generated on the command line. The way we use Cocoon at Hippo seems to be something of a combination of these two approaches: an http server running an instance of Cocoon functions

AbstractSAXTransformer logging (Re: cvs commit: ... AbstractSAXTransformer.java)

I'm not too sure of this commit. The problem is that AbstractSAXTransformer's debug-level logging is so verbose that it swamps the debug logs of its children with stuff like this: DEBUG (/forrest/body-index.html): BEGIN endTransformingElement uri=, name=link, raw=link) DEBUG (/forrest/body-i

cvs commit: cocoon-2.1/src/java/org/apache/cocoon/transformation AbstractSAXTransformer.java

jefft 2003/06/18 05:22:07 Modified:src/java/org/apache/cocoon/transformation AbstractSAXTransformer.java Log: Add a boolean field determining whether to log SAX events (primarily element start/endTransformingElement() calls). Occasionally these SAX logs a

RE: Why does moving the portal-fw from samples break it? (PortalManager not found on 'save')

> -Original Message- > From: Rob Johnston [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 17, 2003 8:11 PM > To: [EMAIL PROTECTED] > Subject: Why does moving the portal-fw from samples break it? > (PortalManager not found on 'save') > > > I've attempted to move the portal-fw sample from

cvs commit: cocoon-2.1/src/java/org/apache/cocoon/transformation AbstractSAXTransformer.java

jefft 2003/06/18 05:11:07 Modified:src/java/org/apache/cocoon/transformation AbstractSAXTransformer.java Log: Remove redundant '== true' in boolean expression Revision ChangesPath 1.2 +27 -27 cocoon-2.1/src/java/org/apache/cocoon/transf

cvs commit: cocoon-2.1/src/documentation/xdocs/installing updating.xml

cziegeler2003/06/18 05:10:29 Modified:src/documentation/xdocs/installing updating.xml Log: Minor typos Revision ChangesPath 1.8 +4 -3 cocoon-2.1/src/documentation/xdocs/installing/updating.xml Index: updating.xml =

cvs commit: cocoon-2.1/src/documentation/xdocs/installing updating.xml

bdelacretaz2003/06/18 05:01:17 Modified:src/documentation/xdocs/installing updating.xml Log: proofreading and general cleanup Revision ChangesPath 1.7 +106 -94 cocoon-2.1/src/documentation/xdocs/installing/updating.xml Index: updating.xml ==

Re: Hibernate sessions (was Re: [vote results] FOM)

On Wednesday, June 18, 2003, at 10:53 AM, Ugo Cei wrote: Jeremy Quinn wrote: I open a new Hibernate Session at Function invocation, closing it on exit. FWIW, I've used this pattern in the past and it caused me some problems. In particular, you risk leaving a session open whenever the user does

cvs commit: cocoon-2.1/src/blocks/axis/java/org/apache/cocoon/reading AxisRPCReader.java

giacomo 2003/06/18 04:18:35 Modified:src/blocks/axis/lib commons-discovery.jar wsdl4j.jar src/blocks/axis/samples sitemap.xmap lib jars.xml .status.xml src/blocks/axis/java/org/apache/cocoon/reading

cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/sitemap ComponentsSelector.java SitemapLanguage.java

cziegeler2003/06/18 04:06:31 Modified:.status.xml src/java/org/apache/cocoon/components ExtendedComponentSelector.java CocoonComponentManager.java src/java/org/apache/cocoon/components/treeprocessor/sit

Re: [Flow] Scope and Sessions

Marc Portier wrote: Sylvain Wallez wrote: Geissel, Adrian wrote: Just a thought: From a technical point of view, are there any other possiblities of implementing the JavaScript global scope. I assume this is a question. The request is obviously not good at this and the servlet cont

Hibernate sessions (was Re: [vote results] FOM)

Jeremy Quinn wrote: I open a new Hibernate Session at Function invocation, closing it on exit. FWIW, I've used this pattern in the past and it caused me some problems. In particular, you risk leaving a session open whenever the user does not complete the form submission. In my latest project, I'

Re: [vote results] FOM

On Wednesday, June 18, 2003, at 12:51 AM, Pier Fumagalli wrote: On 17/6/03 22:51, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: - Should the flow _always_ be associated with a Session? I haven't written a flowscript that didn't require, in some way or another, the availability of some statefuln

Divorse Cocoon creation from CocoonServlet

Hi all, I'd like to override getCocoon method in CocoonServlet in order to allow another subsystem than the servlet create and manage Cocoon. This so that the same Cocoon instance can be shared among different clients adapting different protocols. More specifically I want to be able to have Cocoon

cvs commit: cocoon-2.1/src/blocks/linotype/samples flow.js

stevenn 2003/06/18 02:27:45 Modified:src/blocks/linotype/samples flow.js Log: flame at will, maybe this fixes part of the path problem, if we can live with the assumption URI & sitemap layout are similar Revision ChangesPath 1.3 +8 -5 cocoon-2.1/src/blocks/lin

Re: [Flow] Scope and Sessions

Sylvain Wallez wrote: Geissel, Adrian wrote: Just a thought: From a technical point of view, are there any other possiblities of implementing the JavaScript global scope. I assume this is a question. The request is obviously not good at this and the servlet context is way too broad. An

Re: [RFI] Garbage

"Bertrand Delacretaz" <[EMAIL PROTECTED]> wrote: > Le Mercredi, 18 juin 2003, à 02:07 Europe/Zurich, Pier Fumagalli a > écrit : >> >> ...It might not go anywhere, it might go somewhere, but if there's >> interest in >> this community to host my "Garbage" template engine, all I ask is to >> have a

Re: [RFI] Garbage

"Christopher Oliver" <[EMAIL PROTECTED]> wrote: > Cool. When can I try it? I'll help you as long as you stop calling it > garbage ;) I'll stop calling it garbage when it'll stop looking (and behaving) like trash. Pier

Re: [RFI] Garbage

"Vadim Gritsenko" <[EMAIL PROTECTED]> wrote: > Pier Fumagalli wrote: > ... > >> So, what do you think? (Surely I need some help to put together the brat) >> >> > > If it provides getKey and getValidity, than it's much better velocity > than velocity in the cocoon-land! You talking about cach

RE: Design bug or implementation bug in redirector?

> From: Upayavira [mailto:[EMAIL PROTECTED] > > > details. Why not providing a way of passing through all parameters? > > I've never used it, but I believe you can do > {request:queryString} or something like > that to get the query string out of the request object. Then > you do something lik

Re: Linotype editing: browser requirements?

Gianugo Rabellino wrote: BTW, Stefano: Linotype *really* kicks ass. Problem is that from you we aren't expecting anything less, so this is why you are not getting all the kudos you deserve. :-) But it's really, really, really a good job! Yep. I just tried it for the first time. Edited a bit

Re: TreeProcessor:BUG

Sylvain Wallez wrote: Klaus Bertram wrote: Hi Joerg yes I found it by debugging an action where the breakpoint was stoped twice. So I wrote a small test sidemap with an xsp side and database actions By request the map:aggregation match, an action in map:part add a row to the databse and then

Re: Linotype editing: browser requirements?

Gianugo Rabellino wrote: Anyway, I'm wondering why the multipart request. Is it because of images? If it weren't for images, wouldn't it be better to POST a text/xml body with all the necessary information, putting the "verb" (save, delete, etc.) in the URI, in the style of REST? Probably so. An

Re: [Flow] Scope and Sessions

Geissel, Adrian wrote: So the flow state is transmitted through a single value, the continuation identifier, which can be either in a hidden field or in the submit URI. This is what I was trying to say :) By storing the continuation id (perhaps correlated with the session for securit

Re: TreeProcessor:BUG

Klaus Bertram wrote: Hi Joerg yes I found it by debugging an action where the breakpoint was stoped twice. So I wrote a small test sidemap with an xsp side and database actions By request the map:aggregation match, an action in map:part add a row to the databse and then the xsp read the table

Re: Linotype editing: browser requirements?

Ugo Cei wrote: >> No, no need for that. It took me half an hour to figure that problem out myself and it's an indication of how generally badly designed is cocoon's handling of multipart-encoded POST requests. Could it be useful to document this "feature" along with the usage instructions? I ju

RE: [Flow] Scope and Sessions

> So the flow state is transmitted through a single value, the > continuation identifier, which can be either in a hidden > field or in the > submit URI. > This is what I was trying to say :) By storing the continuation id (perhaps correlated with the session for security - ie. a user has a

Re: TreeProcessor:BUG

Hi Joerg yes I found it by debugging an action where the breakpoint was stoped twice. So I wrote a small test sidemap with an xsp side and database actions By request the map:aggregation match, an action in map:part add a row to the databse and then the xsp read the table entrys. The browser sh

Re: [Flow] Scope and Sessions

Geissel, Adrian wrote: Just a thought: From a technical point of view, are there any other possiblities of implementing the JavaScript global scope. I assume this is a question. The request is obviously not good at this and the servlet context is way too broad. Any other mechanism wo

cvs commit: cocoon-2.1/src/blocks/linotype TODO.txt

stevenn 2003/06/18 00:18:48 Modified:src/blocks/linotype TODO.txt Log: added feature idea for further work on linotype Revision ChangesPath 1.2 +2 -0 cocoon-2.1/src/blocks/linotype/TODO.txt Index: TODO.txt

Re: Linotype editing: browser requirements?

Stefano Mazzocchi wrote: Weird. Try upgrading to 1.3.1 Oh well, since I've tested it under 1.4 and it works, I'm going to skip that version. Thank you. Ugo -- Ugo Cei - http://www.beblogging.com/blog/

Re: Linotype editing: browser requirements?

Stefano Mazzocchi wrote: No, no need for that. It took me half an hour to figure that problem out myself and it's an indication of how generally badly designed is cocoon's handling of multipart-encoded POST requests. Could it be useful to document this "feature" along with the usage instructions?

Re: A proposal for a best practice project

Le Lundi, 16 juin 2003, à 08:56 Europe/Zurich, Ross Gardler a écrit : .. The purpose of this mail is twofold: 1) notify the community of this project.. Thanks, your project sounds interesting to me. I think it would be good to include such best practices app as blocks in Cocoon, so that people

RE: [Flow] Scope and Sessions

Just a thought: > > From a technical point of view, are there any other possiblities > > of implementing the JavaScript global scope. > > I assume this is a question. The request is obviously not good at this > and the servlet context is way too broad. Any other mechanism > would be a > data c

DO NOT REPLY [Bug 10694] - No default for pipelines causes existing cocoon installs to crash

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