DO NOT REPLY [Bug 21703] - [PATCH] RequestGenerator

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 21703] - [PATCH] RequestGenerator

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 21379] - fo2pdf serialization problem

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 20308] - 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 . 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 21855] - [PATCH] Namespace bug in FragmentExtractorTransformer

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 21855] - Namespace bug in FragmentExtractorTransformer

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: cocoon-2.1/src/blocks/batik/java/org/apache/cocoon/transformation FragmentExtractorTransformer.java

joerg 2003/07/29 19:24:43 Modified:src/blocks/batik/java/org/apache/cocoon/transformation FragmentExtractorTransformer.java Log: fixing bug 21855: namespace uri as empty string instead of null (spotted by Martin Holz) Revision ChangesPath 1.4

cvs commit: cocoon-2.1/src/blocks/deli/java/org/apache/cocoon/components/deli DeliImpl.java

joerg 2003/07/29 19:21:31 Modified:src/java/org/apache/cocoon/servlet BootstrapServlet.java src/java/org/apache/cocoon/servlet/multipart MultipartHttpServletRequest.java src/blocks/deli/java/org/apache/cocoon/components/deli

Re: [RT] Revisiting Woody's form definition

Steven Noels dijo: > On 29/07/2003 18:52 Sylvain Wallez wrote: > >> And how good it is to see people having so deep the understanding of >> opensource values and benefits. > > ... this being the standard in this fine community. Apart from some core > values, most of my clue w.r.t. the mix of open

Re: [RT] Woody and round trip of parameters.

Marc Portier dijo: > some attempt/proposal: > definition-model declares field: > case A: nothing special -> defaults to read-write > case B: as being read-only > case C: specific as read-write > > binding declared on field > case 1: nothing special -> defaults to inherited from the field > defini

Re: [RT] Woody and round trip of parameters.

Sylvain Wallez dijo: > I guess Antonio is talking about computed fields. For example, the > "subtotal" above is the sum of all "amount" fields. Amounts are > read-only, and subtotal is a fake field that has no binding to the > application data model. Yep. This is the idea. Also note this type of f

Re: [RT] Woody and round trip of parameters.

Bruno Dumon dijo: > On Tue, 2003-07-29 at 15:07, Antonio Gallardo wrote: >> Hi: >> >> I had a concern about how to manage parameters that are flying between >> the server and the client. >> >> It will worth if we have an attribute in the form that define when we >> are waiting or not for a paramete

Re: Discussion of Cocoon TLP Guidelines

Steven Noels wrote: If it comes to (a) vote(s), anybody's opinion is appreciated, so please speak up. Binding votes about the Cocoon guidelines can be cast by Cocoon committers only - the original members of the 'founding' PMC that is. I guess that as long as Lenya is under incubation, Lenya

Re: [RT] Revisiting Woody's form definition

On Tue, 2003-07-29 at 18:31, Sylvain Wallez wrote: > Bruno Dumon wrote: > > >On Tue, 2003-07-29 at 17:23, Sylvain Wallez wrote: > > > > > > >>As for disposal, the TreeProcessor maintains a list of all Disposable > >>nodes created by the builders that are disposed when the sitemap itself > >>i

DO NOT REPLY [Bug 21925] - FOM Request object does not provide access to all the request's values

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: [RT] Webdavapps with Cocoon

Stefano wrote: > > If I have a resource like > > > > http://blah.com/news/ > > > > and I want to edit, I could ask for > > > > http://blah.com:/news/ > > http://edit.blah.com/news/ > > http://blah.com/news/?view="edit"; > > > > which are all 'orthogonal' ways of asking a different view > o

ToDo about excalibur libs

I found this todo in the status file: For 2.1: use (only) released versions of excalibur (collections, concurrent, source, store, xmlutil). This requires a release of those components in excalibur. In my Eclipse workspace Cocoon compile without "excalibur collections" and "exc

Re: Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/sitemapSwitchSelectNode.java

>Carsten Ziegeler wrote: >>Sylvain Wallez wrote: >> >> >>>Carsten, >>> >>>I couldn't find Volker's report, but I think it's the selector's >>>responsibility to handle the case when it returns a null context object >>>and that the sitemap should not enforce a failure in that case. >>>Furthermore,

Re: Hibernate vs. OJB

Leszek Gawron dijo: > 1. I have a feeling that Hibernate makes it easier to model more > advanced structures. I did not get the feeling with OJB. This is just a feeling. The O/R mapping is here for a while and it allow to make complex models. I think the both can manage complex models. The models

Re: Hibernate vs. OJB

- Original Message - From: "Leszek Gawron" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, July 29, 2003 10:02 AM Subject: Re: Hibernate vs. OJB > 2. The OJB tutorial (IBM site) states that it is difficut to use it with IDEs > as it enables persistence to classes by modyfying

DO NOT REPLY [Bug 5978] - Java SecurityManager java.lang.RuntimePermission createSecurityManager required for cocoon 2

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_bug

Re: Hibernate vs. OJB

On Tue, Jul 29, 2003 at 08:47:46AM -0800, JD Daniels wrote: > The "persistence layer" was completely new to me as well. (It was Flow that > got me interested) Hibernate confuse dthe crap out of me. After Antonio's > wiki :http://wiki.cocoondev.org/Wiki.jsp?page=OJBWithJDO > well, JDO makes *sense*

DO NOT REPLY [Bug 16580] - Java compiler requires JARs in the FS; can not use classloader

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 16580] - Java compiler requires JARs in the FS; can not use classloader

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: cocoon-2.0/src/java/org/apache/cocoon/components/language/programming/java eclipse.xconf

vgritsenko2003/07/29 11:55:42 Added: src/java/org/apache/cocoon/components/language/programming/java eclipse.xconf Log: Backport eclipse compiler from 2.1 Revision ChangesPath 1.1 cocoon-2.0/src/java/org/apache/cocoon/components

cvs commit: cocoon-2.0/lib/optional jdtcore-2.1.0.jar

vgritsenko2003/07/29 11:50:38 Added: legalLICENSE.jdtcore lib/optional jdtcore-2.1.0.jar Log: Backport eclipse compiler from 2.1 Revision ChangesPath 1.1 cocoon-2.0/legal/LICENSE.jdtcore Index: LICENSE.jdtcore =

cvs commit: cocoon-2.0/src/java/org/apache/cocoon/components/language/programming/java EclipseJavaCompiler.java JavaLanguage.java Jikes.java NullFormatter.java javac.xconf pizza.xconf

vgritsenko2003/07/29 11:49:30 Modified:.changes.xml build.xml lib jars.xml src/java/org/apache/cocoon/components/language/programming/java JavaLanguage.java Jikes.java NullFormatter.java javac.xcon

DO NOT REPLY [Bug 15806] - Doctype is added twice

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: cocoon-2.0/src/webapp sitemap.xmap

vgritsenko2003/07/29 11:02:57 Modified:src/webapp sitemap.xmap Log: Add comment about html4 doctype. Align serializer's definitions. Revision ChangesPath 1.6 +51 -48cocoon-2.0/src/webapp/sitemap.xmap Index: sitemap.xmap ===

DO NOT REPLY [Bug 15806] - Doctype is added twice

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: cocoon-2.1/src/blocks/linotype/samples sitemap.source.xmap sourceflow.js

gianugo 2003/07/29 10:59:29 Modified:src/blocks/linotype/samples sitemap.source.xmap sourceflow.js Log: Pipeline needs to be non caching, something to investigate. Also, while at it, made sourceflow.js more general. Revision ChangesPath 1.3

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

gianugo 2003/07/29 10:55:36 Added: src/blocks/linotype/samples/stylesheets hierarchy2cinclude.xslt Log: Added this missing stylesheet for the source-based version of Linotype Revision ChangesPath 1.1 cocoon-2.1/src/blocks/linoty

DO NOT REPLY [Bug 12291] - JispStore does not implement keys()

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 12291] - JispStore does not implement keys()

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: cocoon-2.0/lib/optional jisp-2.5.1.jar jisp_1_0_2.jar

vgritsenko2003/07/29 10:41:30 Modified:.changes.xml src/java/org/apache/cocoon/components/store JispFilesystemStore.java JispStringKey.java lib jars.xml Added: lib/optional jisp-2.5.1.jar Removed: lib/option

cvs commit: cocoon-2.1/src/blocks/html/java/org/apache/cocoon/transformation HTMLTransformer.java

gianugo 2003/07/29 10:03:38 Modified:src/blocks/html/java/org/apache/cocoon/transformation HTMLTransformer.java Log: Normalize whitespace Revision ChangesPath 1.3 +1 -1 cocoon-2.1/src/blocks/html/java/org/apache/cocoon/transformation/HT

Re: [RT] Revisiting Woody's form definition

On 29/07/2003 18:52 Sylvain Wallez wrote: And how good it is to see people having so deep the understanding of opensource values and benefits. ... this being the standard in this fine community. Apart from some core values, most of my clue w.r.t. the mix of open source code, communities and bus

Re: [RT] Revisiting Woody's form definition

Steven Noels wrote: On 29/07/2003 18:17 Sylvain Wallez wrote: Marc Portier wrote I do understand this might break some backwards compat stuff, but the block is labeled 'unstable' and 'alfa' precisely because we know this is bound to happen nevertheless Bruno is doing an effort to notify the

Re: [RT] Revisiting Woody's form definition

On 29/07/2003 18:17 Sylvain Wallez wrote: Marc Portier wrote I do understand this might break some backwards compat stuff, but the block is labeled 'unstable' and 'alfa' precisely because we know this is bound to happen nevertheless Bruno is doing an effort to notify the users list of importa

Re: [RT] Revisiting Woody's form definition

Bruno Dumon wrote: On Tue, 2003-07-29 at 17:23, Sylvain Wallez wrote: As for disposal, the TreeProcessor maintains a list of all Disposable nodes created by the builders that are disposed when the sitemap itself is disposed (BTW, thanks Carsten for finding that nodes should be disposed in re

Re: Treeprocessor bug with map:resource and views?

Vadim Gritsenko wrote: Geoff Howard wrote: Vadim Gritsenko wrote: Hi guys, Check out the samples. Most of them work ok, with the exception of i18n samles -- click on content view or links view and see the results. i18n samples use aggregation and resources in the sitemap with the label on one

Re: [RT] Revisiting Woody's form definition

Marc Portier wrote: Sylvain Wallez wrote: Marc Portier wrote: Sylvain, This perfectly alligns with how I have been thinking about extracting and embracing the nice ideas your first RT was bringing to the scene... Cool ;-) it is called 'shared neurons' :-) my (not Bruno's) planning: 1

Re: Preparing for 2.2

On 29/07/2003 17:40 Sylvain Wallez wrote: Yep. I'm strongly -1 to a new repo if we loose history... Ditto - apart from very ancient modules with lots of Attic stuff where CVS becomes very slow, it spoils the possibility of doing nice stats. I do find branches a tad more evil, however, so if 2.2

RE: [RT] Webdavapps with Cocoon

Gianugo Rabellino <[EMAIL PROTECTED]> writes: > Having these advanced "xml-rpc" capabilities would men a hell > of a lot > for Cocoon NG: as one of my bosses pointed out this morning, this is > exactly what would be missing to use Cocoon as the perfect EAI tool > (yes, I know that you don't gi

Re: Preparing for 2.2

Gianugo Rabellino wrote: Vadim Gritsenko wrote: Another thing to keep in mind is that if everybody starts developing 2.2 and nobody works on 2.1+, then it makes sense to copy all of the blocks to 2.2 as well, and 2.1 will become "historical". Please don't call it like this. Let users have a s

Re: [RT] Revisiting Woody's form definition

On Tue, 2003-07-29 at 17:23, Sylvain Wallez wrote: > > > >Currently it is not checked that the value comming from the request is > >actually in the list. So the list is more of an input-aid then an > >enum-type. > > > >That's also one of the reasons I've moved it out of the datatype, > >together

Re: Hibernate vs. OJB

The "persistence layer" was completely new to me as well. (It was Flow that got me interested) Hibernate confuse dthe crap out of me. After Antonio's wiki :http://wiki.cocoondev.org/Wiki.jsp?page=OJBWithJDO well, JDO makes *sense* heh heh What I mean is Antonios wiki I could get running and unders

Re: [RT] Woody and round trip of parameters.

Sylvain Wallez wrote: Bruno Dumon wrote: I guess Antonio is talking about computed fields. For example, the "subtotal" above is the sum of all "amount" fields. Amounts are read-only, and subtotal is a fake field that has no binding to the application data model. I'm wondering if "read-only

Re: Treeprocessor bug with map:resource and views?

Geoff Howard wrote: Vadim Gritsenko wrote: Hi guys, Check out the samples. Most of them work ok, with the exception of i18n samles -- click on content view or links view and see the results. i18n samples use aggregation and resources in the sitemap with the label on one aggregated part. When

Re: Preparing for 2.2

Vadim Gritsenko wrote: Another thing to keep in mind is that if everybody starts developing 2.2 and nobody works on 2.1+, then it makes sense to copy all of the blocks to 2.2 as well, and 2.1 will become "historical". Please don't call it like this. Let users have a stable version for a while b

Re: Preparing for 2.2

Gianugo Rabellino wrote: I'm fine with it, and it sure makes sense if we are to provide blocks in the next version. However, can this be done by CVS "cp" instead than imports? I don't feel like losing the history again... Yep. I'm strongly -1 to a new repo if we loose history... Sylvain -

Re: [RT] Adaptive Caching

On Tuesday, Jul 29, 2003, at 16:58 Europe/Rome, Hunsberger, Peter wrote: Stefano Mazzocchi <[EMAIL PROTECTED]> asks: If you do the Google search you'll notice the references to randomized paging algorithms. I didn't chase these very far other than to determine that at least one author shows tha

Re: Preparing for 2.2

Carsten Ziegeler wrote: Finally, our beta (named rc) is out and I will create the announcements tomorrow to give the mirrors a little bit of time. So, by this, it means, we should only apply bug-fixes and docs to the repository. Now, I think this applies only to the core, we can still change the

Re: [RT] Webdavapps with Cocoon

Stefano Mazzocchi wrote: Careful here: I never said that a "symmetrical design is bad" (actually, I love when designs become symmetrical), what is bad is "symmetry-driven design". The design should be done driven by the constraints where it must operate and it should, at the end, turn out symm

Re: [RT] Revisiting Woody's form definition

Bruno Dumon wrote: On Mon, 2003-07-28 at 22:15, Sylvain Wallez wrote: Convertors -- Convertors (or should it be "converters" ?) hmm, good point. They seem to be both valid. I seem to have a natural tendency to write "convertor", but I'm fine with both. I've noticed that later on i

Re: Treeprocessor bug with map:resource and views?

Vadim Gritsenko wrote: Hi guys, Check out the samples. Most of them work ok, with the exception of i18n samles -- click on content view or links view and see the results. i18n samples use aggregation and resources in the sitemap with the label on one aggregated part. When this pipeline moved fr

RE: [RT] Adaptive Caching

Stefano Mazzocchi <[EMAIL PROTECTED]> asks: > > If you do the Google search you'll notice the references to > randomized > > paging algorithms. I didn't chase these very far other than to > > determine that at least one author shows that they can > perform as good > > as conventional algorith

Re: [RT] Woody and round trip of parameters.

Bruno Dumon wrote: On Tue, 2003-07-29 at 15:07, Antonio Gallardo wrote: Hi: I had a concern about how to manage parameters that are flying between the server and the client. It will worth if we have an attribute in the form that define when we are waiting or not for a parameter back from the u

Re: [RT] Revisiting Woody's form definition

Carsten Ziegeler wrote: I have read most of the RT and think I have understand some parts of it. Now, I agree that keeping the field definitons as short and comprise as possible is good. Now - without reading more of all the discussions and looking into woody - I just wanted to throw in some aspe

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

stephan 2003/07/29 07:29:10 Modified:src/java/org/apache/cocoon/components/treeprocessor/sitemap ActNodeBuilder.java Log: Throw configuration exception if the element is missing. Revision ChangesPath 1.2 +11 -5 cocoon-2.1/src/java/org/a

Re: [RT] Woody and round trip of parameters.

On Tue, 2003-07-29 at 15:07, Antonio Gallardo wrote: > Hi: > > I had a concern about how to manage parameters that are flying between the > server and the client. > > It will worth if we have an attribute in the form that define when we are > waiting or not for a parameter back from the user? do

Re: [RT] Revisiting Woody's form definition

On Mon, 2003-07-28 at 22:15, Sylvain Wallez wrote: > Convertors > -- > > Convertors (or should it be "converters" ?) hmm, good point. They seem to be both valid. I seem to have a natural tendency to write "convertor", but I'm fine with both. I've noticed that later on in this mail you've

Treeprocessor bug with map:resource and views?

Hi guys, Check out the samples. Most of them work ok, with the exception of i18n samles -- click on content view or links view and see the results. i18n samples use aggregation and resources in the sitemap with the label on one aggregated part. When this pipeline moved from the resource to the

cvs commit: cocoon-2.0/lib/optional fop-0.20.5.jar fop-0.20.4.jar

vgritsenko2003/07/29 06:54:33 Modified:.changes.xml lib jars.xml Added: lib/optional fop-0.20.5.jar Removed: lib/optional fop-0.20.4.jar Log: Update FOP to the latest release Revision ChangesPath 1.30 +5 -2 cocoon-2.0/ch

Re: [Vote] Ugo Cei and Marc Portier as Cocoon committers

On Mon, 28 Jul 2003, Sylvain Wallez wrote: > I'd like to propose two people for Cocoon committership : Ugo Cei and > Marc Portier. > > Please cast your votes. +1 for both - congratulations guys! Andrew. -- Andrew SavoryEmail: [EMAIL PROTECTED] Managing Director

RE: Preparing for 2.2

Marc Portier wrote: > > Vadim Gritsenko wrote: > > Carsten Ziegeler wrote: > > > > > > >> We decided to create a new repository for each major version, so this > >> would require to create a cocoon-2.2 repository. > >> > > > > Another thing to keep in mind is that if everybody starts > developing 2

RE: Preparing for 2.2

Vadim Gritsenko wrote: > > Up to the 2.1 release only. After that, 2.1.1-dev starts. > Yes, of course. > > >We now have to decide how to move on from here in order to start the > >development for 2.2. > > > > Or 2.1.1? I suggest we first discuss what we are planning to do, and see > wether th

[RT] Woody and round trip of parameters.

Hi: I had a concern about how to manage parameters that are flying between the server and the client. It will worth if we have an attribute in the form that define when we are waiting or not for a parameter back from the user? I know woody has some formulas, I was not full review woody. :) I wa

Re: Preparing for 2.2

Vadim Gritsenko wrote: Carsten Ziegeler wrote: We decided to create a new repository for each major version, so this would require to create a cocoon-2.2 repository. Another thing to keep in mind is that if everybody starts developing 2.2 and nobody works on 2.1+, then it makes sense to copy

RE: [RT] Revisiting Woody's form definition

Hi: Comments below :) Carsten Ziegeler dijo: > Validation > -- > It's good to have the possibility to define validation in the form and > at the fields. But in some cases your business objects can > validate their values as well and you don't want to code it twice. If we are going to

Re: Preparing for 2.2

Carsten Ziegeler wrote: So, by this, it means, we should only apply bug-fixes and docs to the repository. Up to the 2.1 release only. After that, 2.1.1-dev starts. Now, I think this applies only to the core, we can still change the blocks, at least the blocks marked as alpha. Yes. We now have

[flow] end of life of the WebContinuation

Hi all, some 2nd thoughts on my earlier proposal: 4/ dispose() the wrapped continuation object upon invalidation I'ld like the ContinuationsManager to check if the wrapped continuation is implementing Disposable upon invalidation of it's wrapper WebContinuation. While at it it might preform t

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

cziegeler2003/07/29 05:32:18 Modified:.status.xml src/java/org/apache/cocoon/transformation CIncludeTransformer.java Log: Fix the ignoreErrors handling in the cinclude transformer Revision ChangesPath 1.99 +4 -2 coc

RE: [RT] Revisiting Woody's form definition

I have read most of the RT and think I have understand some parts of it. Now, I agree that keeping the field definitons as short and comprise as possible is good. Now - without reading more of all the discussions and looking into woody - I just wanted to throw in some aspects which I think are cur

Re: [RT] Revisiting Woody's form definition

Sylvain Wallez wrote: Marc Portier wrote: Sylvain, This perfectly alligns with how I have been thinking about extracting and embracing the nice ideas your first RT was bringing to the scene... Cool ;-) it is called 'shared neurons' :-) my (not Bruno's) planning: 1/ prep up for a local se

Re: [RT] Revisiting Woody's form definition

Marc Portier wrote: Sylvain, This perfectly alligns with how I have been thinking about extracting and embracing the nice ideas your first RT was bringing to the scene... Cool ;-) It also shows you have a more elaborate (lots of forms?) case at hand you want to tackle with Woody, so I really

Re: [PATCH] japanized src/webapp/samples/i18n/translations/

On Mon, 28 Jul 2003 22:40:25 -0400 Vadim Gritsenko <[EMAIL PROTECTED]> wrote: > Tetsuya Kitahata wrote: > >Here I put (attached) a zipped file named "i18n_japanized_sample.zip", > >which contains: > >1. messages_ja.xml > >2. menu_ja.xml > Ok, checked in, but I have no even slightest idea what's

Re: [RT] Webdavapps with Cocoon

Nicola Ken Barozzi wrote: Sylvain Wallez wrote, On 29/07/2003 9.35: It's basically RequestFactories coming back on the table. But this time, this must be more than a simple class to handle file uploads. Yes, IMHO we need another concept, and present it in the sitemap. Before, I had call

RE: cvs commit: cocoon-site/src/documentation/content/xdocs guidelines.xml

Yes, I noticed that as well and already reverted :) Sorry. Carsten > -Original Message- > From: Steven Noels [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 29, 2003 11:41 AM > To: [EMAIL PROTECTED] > Subject: Re: cvs commit: cocoon-site/src/documentation/content/xdocs > guidelines.xml >

RE: Discussion of Cocoon TLP Guidelines

Steven Noels wrote: > Please take your time reading through it, it ain't as bad as it looks > like, and it concerns you: developers & contributors of the Cocoon > project(s). And let's try and keep this as lightweight as feasible. > I read most of it and I think it's a very good start. I have two

Re: cvs commit: cocoon-site/src/documentation/content/xdocs guidelines.xml

On 29/07/2003 11:34 [EMAIL PROTECTED] wrote: cziegeler2003/07/29 02:34:47 Modified:src/documentation/content/xdocs guidelines.xml Log: "Typo" -allowing them to affect the future of the subproject. +allowing them to affect the future of the project. Euh: it still m

cvs commit: cocoon-site/src/documentation/content/xdocs guidelines.xml

cziegeler2003/07/29 02:39:48 Modified:src/documentation/content/xdocs guidelines.xml Log: Revert "typos" :) Revision ChangesPath 1.5 +2 -2 cocoon-site/src/documentation/content/xdocs/guidelines.xml Index: guidelines.xml ==

cvs commit: cocoon-site/src/documentation/content/xdocs guidelines.xml

cziegeler2003/07/29 02:37:58 Modified:src/documentation/content/xdocs guidelines.xml Log: "Typo" Revision ChangesPath 1.4 +1 -1 cocoon-site/src/documentation/content/xdocs/guidelines.xml Index: guidelines.xml =

cvs commit: cocoon-site/src/documentation/content/xdocs guidelines.xml

cziegeler2003/07/29 02:34:47 Modified:src/documentation/content/xdocs guidelines.xml Log: "Typo" Revision ChangesPath 1.3 +1 -1 cocoon-site/src/documentation/content/xdocs/guidelines.xml Index: guidelines.xml =

cvs commit: cocoon-site/src/documentation/content/xdocs/news index.xml

cziegeler2003/07/29 02:26:52 Modified:src/documentation/content/xdocs/news index.xml Log: Add new release Revision ChangesPath 1.8 +1 -0 cocoon-site/src/documentation/content/xdocs/news/index.xml Index: index.xml =

Re: [RT] Adaptive Caching

On Monday, Jul 28, 2003, at 17:24 Europe/Rome, Hunsberger, Peter wrote: Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: NOTE: this is a refactoring of an email I wrote 2 1/2 years ago. Stefano, had a little more time to read this last week: Memphis got hit by some 85 mph winds, no power at our h

Re: [RT] Revisiting Woody's form definition

Sylvain, This perfectly alligns with how I have been thinking about extracting and embracing the nice ideas your first RT was bringing to the scene... It also shows you have a more elaborate (lots of forms?) case at hand you want to tackle with Woody, so I really think your proposed rationali

cvs commit: cocoon-site/src/documentation/content/xdocs guidelines.xml

stevenn 2003/07/29 02:12:21 Modified:src/documentation/content/xdocs guidelines.xml Log: uh - forgot about these mentionings of Jakarta Revision ChangesPath 1.2 +3 -3 cocoon-site/src/documentation/content/xdocs/guidelines.xml Index: guidelines.xml ==

Discussion of Cocoon TLP Guidelines

Dear all, I've just checked in a verbatim copy of the Jakarta Guidelines (located at http://jakarta.apache.org/site/proposal.html) in the cocoon-site module, that could serve as a starter to base our own project guidelines upon. Before we became a TLP (top level project), we were supposed to f

Preparing for 2.2

Finally, our beta (named rc) is out and I will create the announcements tomorrow to give the mirrors a little bit of time. So, by this, it means, we should only apply bug-fixes and docs to the repository. Now, I think this applies only to the core, we can still change the blocks, at least the bl

cvs commit: cocoon-site/src/documentation/content/xdocs site.xml

stevenn 2003/07/29 02:03:18 Modified:src/documentation/content/xdocs site.xml Log: making sure guidelines aren't inadvertently put live before a proper vote Revision ChangesPath 1.10 +6 -1 cocoon-site/src/documentation/content/xdocs/site.xml Index: site.xml

End of Code Freeze

The rc1 is currently uploading into our dist directory. So, we can fix bugs again :) Carsten

Re: [RT] Webdavapps with Cocoon

On Tuesday, Jul 29, 2003, at 10:19 Europe/Rome, Nicola Ken Barozzi wrote: So in reality, there should be a kind of mechanism *before* Generation that is able to present the sitemap with payloads as urls and Requests in the content as Request data. This mechanism must occur not only before gener

cvs commit: cocoon-2.1 status.xml forrest.properties

cziegeler2003/07/29 02:01:01 Modified:src/java/org/apache/cocoon cocoon.properties .status.xml forrest.properties Log: Starting next version Revision ChangesPath 1.12 +1 -1 cocoon-2.1/src/java/org/apache/cocoon/cocoon.properties Index

Re: [RT] Webdavapps with Cocoon

On Monday, Jul 28, 2003, at 20:49 Europe/Rome, Guido Casper wrote: A webdavapp is always stateless on the server as the (fat) client manages the state. So it should be possible (and more maintainable in the long run?) to build a webdavapp in a mostly declarative fashion. Yes, I agree. -- Stefan

Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/sitemapSwitchSelectNode.java

Carsten Ziegeler wrote: Sylvain Wallez wrote: Carsten, I couldn't find Volker's report, but I think it's the selector's responsibility to handle the case when it returns a null context object and that the sitemap should not enforce a failure in that case. Furthermore, this modification prevent

Re: [RT] Webdavapps with Cocoon

On Monday, Jul 28, 2003, at 18:57 Europe/Rome, Gianugo Rabellino wrote: Stefano Mazzocchi wrote: the single pieces that make that result happen. Even the simplest XSLT transformation can't be reversely applied, so now there is no way to understand how an resource should be treated in a symmetri

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

cziegeler2003/07/29 01:46:00 Modified:src/java/org/apache/cocoon/components/treeprocessor/sitemap SwitchSelectNode.java Log: Reverting changes Revision ChangesPath 1.3 +1 -8 cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor

RE: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/sitemap SwitchSelectNode.java

Sylvain Wallez wrote: > Carsten, > > I couldn't find Volker's report, but I think it's the selector's > responsibility to handle the case when it returns a null context object > and that the sitemap should not enforce a failure in that case. > Furthermore, this modification prevents execution of th

Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/sitemapSwitchSelectNode.java

[EMAIL PROTECTED] wrote: cziegeler2003/07/28 23:28:55 Modified:src/java/org/apache/cocoon/components/treeprocessor/sitemap SwitchSelectNode.java Log: Fixing NPE. Thanks to Volker! Revision ChangesPath 1.2 +9 -3 cocoon-2.1/src/java/org/apache/c

  1   2   >