Another XSP?

"Introducing XML Server Pages - XSP" "XSP technology is a revolutionary innovation from Trilog built to improve both the development and execution of powerful Web applications. As the core technology in FlowBuilder XML Edition, XML Server Pages (XSPs) provide the framework to create dynamic app

todo list for Flow

Ovidiu, perhaps you should follow our example of a todo list for docs, to get your list out in the open. src/documentation/xdocs/plan/todo-doc.xml Having it hidden in with the Java code does not really encourage people to work on it. --David > From: [EMAIL PROTECTED] > Subject: cvs commit: > xml-

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

vgritsenko2002/10/28 21:42:41 Modified:src/webapp/WEB-INF Tag: cocoon_2_0_3_branch web.xml Log: CocoonServlet upload behavior now configurable from the web.xml. Configuration parameters are: autosave-uploads, overwrite-uploads, upload-max-size. See web.xml for description. Than

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

vgritsenko2002/10/28 21:42:41 Modified:src/webapp/WEB-INF web.xml Log: CocoonServlet upload behavior now configurable from the web.xml. Configuration parameters are: autosave-uploads, overwrite-uploads, upload-max-size. See web.xml for description. Thanks to Geoff Howard.

DO NOT REPLY [Bug 13648] - [PATCH] Makes file upload behaviour configurable

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/servlet CocoonServlet.java

vgritsenko2002/10/28 21:29:18 Modified:.changes.xml src/java/org/apache/cocoon/servlet CocoonServlet.java Log: CocoonServlet upload behavior now configurable from the web.xml. Configuration parameters are: autosave-uploads, overwrite-uploads, upload-max-siz

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/servlet CocoonServlet.java

vgritsenko2002/10/28 21:29:00 Modified:.Tag: cocoon_2_0_3_branch changes.xml src/java/org/apache/cocoon/servlet Tag: cocoon_2_0_3_branch CocoonServlet.java Log: CocoonServlet upload behavior now configurable from the web.xml. C

Re: [PROPOSAL] Pipeline Level Flow Extension

Hi Michael, On Monday, Oct 28, 2002, at 07:25 US/Pacific, Michael Melhem wrote: Hello Cocooners, I have a proposal for "pipeline level flowmaps" (and flowmap chaining) as an extention to the existing sitemap-level flowmaps. This proposal is based on the assumption that at the moment, each site

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/flow TODO

ovidiu 2002/10/28 21:14:55 Added: src/java/org/apache/cocoon/components/flow TODO Log: Added from src/scratchpad/schecoon/. Revision ChangesPath 1.1 xml-cocoon2/src/java/org/apache/cocoon/components/flow/TODO Index: TODO

DO NOT REPLY [Bug 13643] - [PATCH] Finer granularity for RequestFactory impl choice

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/servlet CocoonServlet.java

vgritsenko2002/10/28 20:49:52 Modified:.changes.xml src/java/org/apache/cocoon/components/request MaybeUploadRequestFactoryImpl.java RequestFactory.java src/java/org/apache/cocoon/environment/http

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/servlet CocoonServlet.java

vgritsenko2002/10/28 20:48:59 Modified:.Tag: cocoon_2_0_3_branch changes.xml src/java/org/apache/cocoon/components/request Tag: cocoon_2_0_3_branch MaybeUploadRequestFactoryImpl.java RequestFac

Re: build system [was: scratchpad blocks]

Torsten Curdt wrote: while implementing the scratchpad blocks... I am fine with that... So I'll go for ...I found some things I like to hear some opinions on before changing the whole build system ;-) 1. I found that the status="unstable" should be not in t

Re: CaheValidity & toString()

Stephen Ng wrote: PS In the meantime, workaround is to use such System IDs (cocoon:// URLs) that have same information as a key, because System IDs are not ignored. Is this possible if the difference is only in the query string? Yes, see SitemapSource.java: // create system ID

cvs commit: xml-cocoon2/src/webapp/samples samples.xml

ivelin 2002/10/28 19:28:28 Modified:src/webapp/samples samples.xml Log: added a more sophisticated demo for the WebServiceProxyGenerator. Show cases virtual portal embedding Amazon and OpenWiki Revision ChangesPath 1.32 +8 -1 xml-cocoon2/src/webapp/samples/s

cvs commit: xml-cocoon2/src/webapp/samples/webserviceproxy/cocoonhive/amazon listMania2xhtml.xsl bookInfo2xhtml.xsl bookInfo2page.xsl

ivelin 2002/10/28 19:26:38 Modified:src/webapp/samples/webserviceproxy sitemap.xmap Added: src/webapp/samples/webserviceproxy/cocoonhive sitemap.xmap src/webapp/samples/webserviceproxy/cocoonhive/amazon listMania2xhtml.xsl bookInfo2xhtml.xs

cvs commit: xml-cocoon2/src/webapp/samples/webserviceproxy/cocoonhive - New directory

ivelin 2002/10/28 19:26:24 xml-cocoon2/src/webapp/samples/webserviceproxy/cocoonhive - New directory -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional c

cvs commit: xml-cocoon2/src/webapp/samples/webserviceproxy/cocoonhive/amazon - New directory

ivelin 2002/10/28 19:26:24 xml-cocoon2/src/webapp/samples/webserviceproxy/cocoonhive/amazon - New directory -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For addit

build system [was: scratchpad blocks]

while implementing the scratchpad blocks... > I am fine with that... So I'll go for > > > > ...I found some things I like to hear some opinions on before changing the whole build system ;-) 1. I found that the status="unstable" should be not in the properties.xml f

RE: CaheValidity & toString()

> PS In the meantime, workaround is to use such System IDs (cocoon:// > URLs) that have same information as a key, because System IDs are not > ignored. Is this possible if the difference is only in the query string? If so, I don't understand enough about the sitemap/aggregation/cocoon protocol

Re: CaheValidity & toString()

Stephen Ng wrote: Okay I understand everything you say, but I still think the ContentAggregator code has a problem. It's not second one, it's *the* *same* object. Equal keys == same object. See cacheable.xsp to get an idea, it shows how with the help of a single XSP you can create multiple

RE: CaheValidity & toString()

Okay I understand everything you say, but I still think the ContentAggregator code has a problem. > It's not second one, it's *the* *same* object. Equal keys == same > object. See cacheable.xsp to get an idea, it shows how with > the help of > a single XSP you can create multiple objects (with

Re: CaheValidity & toString()

Stephen Ng wrote: ... which means that these two URLs produce different Validity objects in from-an-xsp pipeline. Is it right? But what about validity? Seems that it changes. Yes the validity changes, but ContentAggregator's key is the same. Yes, of course. If two objects have the

RE: CaheValidity & toString()

> ... which means that these two URLs produce different > Validity objects > in from-an-xsp pipeline. Is it right? > But what about validity? Seems that it changes. > Yes the validity changes, but ContentAggregator's key is the same. If two objects have the same Key, it looks like only the sec

Re: [RT] Getting rid of the table-based layout

Tony Collen wrote: > Steven Noels wrote: > > We could use some helping hands over at Forrest to finish our skins. > > Where do I sign up? :) http://xml.apache.org/forrest/ and send subscribe email to: forrest-dev-subscribexml.apache.org --David ---

DO NOT REPLY [Bug 11727] - [PATCH] lib/core/ -> lib/*/ in build.sh and built.bat

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: CaheValidity & toString()

Stephen Ng wrote: Okay, I think I've found the problem with my aggregate caching. I have an xsp, and I use the cocoon:/ protocol to map:aggregate that xsp. Something like the usual: ... The symptom is that if I ask for http://foo?param=1 and then ask for that same url again, everythin

RE: CaheValidity & toString()

Okay, I think I've found the problem with my aggregate caching. I have an xsp, and I use the cocoon:/ protocol to map:aggregate that xsp. Something like the usual: ... The symptom is that if I ask for http://foo?param=1 and then ask for that same url again, everything appears to be

Re: [RT] Getting rid of the table-based layout

Steven Noels wrote: Miles Elam wrote: But then again, this is all sophostry and rhetoric without something to look at or back it up with. So, getting to my point, I got bored today and made a mockup of http://xml.apache.org/cocoon/ in XHTML 1.0 Strict. http://cocoon.iguanacharlie.com/ I h

Re: Developers docs out of date?

Colin Paul Adams wrote: Looking at /documents/developing/httprequest.html, I see classes mentioned such as: org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage, org.apache.cocoon.sitemap.Handler and org.apache.cocoon.sitemap.Manager for none of which can I find the source

Re: [RT] Getting rid of the table-based layout

Miles Elam wrote: But then again, this is all sophostry and rhetoric without something to look at or back it up with. So, getting to my point, I got bored today and made a mockup of http://xml.apache.org/cocoon/ in XHTML 1.0 Strict. http://cocoon.iguanacharlie.com/ I hope this illustrates my

Re: Howto debug sitemap flowcontrol and xslt-errors ?

SAXESS - Hussayn Dabbous wrote: Concerning XSLT-processing: I found it quite tricky to debug a stylesheet, when i assemble my pages with the tag. Whenever i get an error in one of my stylesheets, the default XSLT seems to silently abort and all i get is an empty page, or a partially constructed

Developers docs out of date?

Looking at /documents/developing/httprequest.html, I see classes mentioned such as: org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage, org.apache.cocoon.sitemap.Handler and org.apache.cocoon.sitemap.Manager for none of which can I find the source code. Am I to assume the

Re: scratchpad blocks

Torsten Curdt wrote: ... Ok? Please, don't use unstable="true" or unstable="false", what about status="stable" and status="unstable". This is interpreted in a stylesheet anyway, so please make it more readable for a casual user. I am fine w

Re: scratchpad blocks

On Mon, 28 Oct 2002, Torsten Curdt wrote: > > I am fine with that... So I'll go for > > > > > > ok? > Looks good for me :) J. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, em

Re: scratchpad blocks

> > > > > > ... > > > > > > > > > > > > > > Ok? > > Please, don't use unstable="true" or unstable="false", what about > status="stable" and status="unstable". > This is interpreted in a stylesheet > anyway, so please make it more readable for a casual

RE: scratchpad blocks

Torsten Curdt wrote: > > > > So we could: > > > > > > 1) leave everything like it is :-( > > > 2) have another blocks directory under scratchpad > > > 3) have a single blocks directory and mark and exclude > scratchpad stuff > > > > 4) have a scratchpad directory in every block that needs it. > >

Re: scratchpad blocks

> > So we could: > > > > 1) leave everything like it is :-( > > 2) have another blocks directory under scratchpad > > 3) have a single blocks directory and mark and exclude scratchpad stuff > > 4) have a scratchpad directory in every block that needs it. > > I'm in favour of 3) excellent - same he

Re: scratchpad blocks

On 28.Oct.2002 -- 04:29 PM, Torsten Curdt wrote: > What about having blocks inside the scratchpad? I just wanted to package the > precept stuff but it should not go into the maintrunk. so... > > I think scratchpad blocks would unify the pattern of creating new stuff... it > also would be a piece

Re: scratchpad blocks

Morrison, John wrote: From: Torsten Curdt [mailto:tcurdt@;dff.st] What about having blocks inside the scratchpad? I just wanted to package the precept stuff but it should not go into the maintrunk. so... I think scratchpad blocks would unify the pattern of creating new stuff... it also woul

Re: scratchpad blocks

On Monday 28 October 2002 16:41, Morrison, John wrote: > > From: Torsten Curdt [mailto:tcurdt@;dff.st] > > > > What about having blocks inside the scratchpad? I just wanted > > to package the > > precept stuff but it should not go into the maintrunk. so... > > > > I think scratchpad blocks would un

cvs commit: xml-cocoon2 changes.xml

tcurdt 2002/10/28 07:48:27 Modified:.changes.xml Log: moved the AbstractMultiAction from scratchpad into maintrunk Revision ChangesPath 1.273 +6 -1 xml-cocoon2/changes.xml Index: changes.xml

RE: scratchpad blocks

> From: Torsten Curdt [mailto:tcurdt@;dff.st] > > What about having blocks inside the scratchpad? I just wanted > to package the > precept stuff but it should not go into the maintrunk. so... > > I think scratchpad blocks would unify the pattern of creating > new stuff... it > also would be a

scratchpad blocks

What about having blocks inside the scratchpad? I just wanted to package the precept stuff but it should not go into the maintrunk. so... I think scratchpad blocks would unify the pattern of creating new stuff... it also would be a piece of cake to move things out of the scratchpad then. On th

[PROPOSAL] Pipeline Level Flow Extension

Hello Cocooners, I have a proposal for "pipeline level flowmaps" (and flowmap chaining) as an extention to the existing sitemap-level flowmaps. This proposal is based on the assumption that at the moment, each sitemap can define *at most one* flow controller as follows: If you consider tha

DO NOT REPLY [Bug 14015] - [PATCH] How To use i18n Transformer with XMLForm Framework

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 14015] - [PATCH] How To use i18n Transformer with XMLForm Framework

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 14015] New: - [PATCH] How To use i18n Transformer with XMLForm Framework

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/blocks/databases/java/org/apache/cocoon/util JDBCTypeConversions.java

tcurdt 2002/10/28 07:02:08 Modified:src/blocks/databases/java/org/apache/cocoon/util JDBCTypeConversions.java Log: fixed jdk 1.2 complience, removed some unused imports, javadoc fixes Revision ChangesPath 1.3 +1 -9 xml-cocoon2/src/bloc

cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/acting PrincipalMultiAction.java SourceMultiAction.java AbstractMethodAction.java MultiAction.java

tcurdt 2002/10/28 06:50:19 Modified:src/scratchpad/src/org/apache/cocoon/acting PrincipalMultiAction.java SourceMultiAction.java Added: src/java/org/apache/cocoon/acting AbstractMultiAction.java Removed: src/scratchpad/src/org/apache/cocoon/acting

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/modules/input EnumerationHelper.java

haul2002/10/28 06:45:28 Removed: src/java/org/apache/cocoon/components/modules/input EnumerationHelper.java Log: Not needed anymore -- In case of troubles, e-mail: [EMAIL PROTECTED] T

cvs commit: xml-cocoon2/lib/optional hsqldb-1.7.1.jar

haul2002/10/28 05:54:24 Modified:lib jars.xml Added: lib/optional hsqldb-1.7.1.jar Log: Updated hsqldb to new version 1.7.1 Revision ChangesPath 1.39 +1 -1 xml-cocoon2/lib/jars.xml Index: jars.xml =

cvs commit: xml-cocoon2/lib/optional hsqldb-1.7.0.jar

haul2002/10/28 05:54:33 Removed: lib/optional hsqldb-1.7.0.jar Log: Updated hsqldb to new version 1.7.1 -- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] Fo

cvs commit: xml-cocoon2/src/webapp/samples/mod-db database.xml

haul2002/10/28 05:52:55 Modified:src/webapp/samples/mod-db database.xml Log: Fix references to old module shorthands Revision ChangesPath 1.3 +3 -3 xml-cocoon2/src/webapp/samples/mod-db/database.xml Index: database.xml ===

cvs commit: xml-cocoon2/src/blocks/databases/java/org/apache/cocoon/util JDBCTypeConversions.java

haul2002/10/28 05:52:01 Modified:src/blocks/databases/java/org/apache/cocoon/util JDBCTypeConversions.java Log: Be more smart on type conversions, esp. numeric types. Revision ChangesPath 1.2 +32 -17 xml-cocoon2/src/blocks/databases/j

DO NOT REPLY [Bug 14003] - bad FOPSerializer reference in global sitemap.xmap

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] Use Forrest to build Cocoon docs

I'm generally in agreement with Ken (in fact I proposed a separate CVS module for docs, powered by a Forrest webapp back in July on forrest-dev), but I agree with David that we need to clarify a number of key issues to make such a transition successful and efficient. While I haven't posted much

Howto debug sitemap flowcontrol and xslt-errors ?

Hy; Is there some logging facility, that shows me, which resources have been utilised for one specific browser-request ? A list of entries in a logfile would be very helpfull for me. From the cocoon config i learn, that the log-objects are all in logmode "DEBUG", hence logging is fully enabled.

DO NOT REPLY [Bug 14012] - [PATCH] Inline comment in cocoon.xconf corrected

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 14012] - [PATCH] Inline comment in cocoon.xconf corrected

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 14012] New: - [PATCH] Inline comment in cocoon.xconf corrected; FAQ for user-roles

> > --- Kjetil Kjernsmo <[EMAIL PROTECTED]> wrote: > > Hello! > > > > I resolved the URIResolver problem by installing > > Tomcat 4.1.12 (still > > don't understand what the problem was, though). So, > > I'm back to trying > > to get user-roles for the mail component working. > > I'm still

DO NOT REPLY [Bug 14012] New: - > Geoff

> > --- Kjetil Kjernsmo <[EMAIL PROTECTED]> wrote: > > Hello! > > > > I resolved the URIResolver problem by installing > > Tomcat 4.1.12 (still > > don't understand what the problem was, though). So, > > I'm back to trying > > to get user-roles for the mail component working. > > I'm still

DO NOT REPLY [Bug 14012] New: - > Geoff

> > --- Kjetil Kjernsmo <[EMAIL PROTECTED]> wrote: > > Hello! > > > > I resolved the URIResolver problem by installing > > Tomcat 4.1.12 (still > > don't understand what the problem was, though). So, > > I'm back to trying > > to get user-roles for the mail component working. > > I'm still

x(ml)forms

Hi, I am thinking about using XForms in one of our projects. As the project is cocoon-based, I had a look at the current developement tree to find out how XMLForms works and if I could "back port" it to the current stable release. It is hard for me to sort things out. Maybe this is because the

Re: DO NOT REPLY [Bug 11518] - [PATCH] Can't use input-module sitemap param with other parameters in same expression

On Sunday 27 October 2002 14:34, [EMAIL PROTECTED] wrote: > [EMAIL PROTECTED] >I think Torsten inadvertently fixed this bug when making other changes to >PreparedVariableResolver. At least, the test I described before no longer >triggers the bug, and upgrading Forrest to the new Cocoon jar fixes t

[SUMMARY]: document() XSLT function not working properly [WAS: Is this as anomaly ?]

Folks, the anomaly I've found (document XSLT function returning a string instead of a node-set) is linked to the Xalan version AND the incremental-processing parameter. It could be summarized as follows: 1) Xalan 2.2.0.D14 and incremental-processing set to "true": Error 2) Xalan 2.2.0.D14 and in