cvs commit: xml-cocoon2/src/scratchpad/src/org/apache/cocoon/sunshine/connector ResourceConnectorImpl.java

cziegeler2002/10/10 23:31:22 Modified:src/scratchpad/src/org/apache/cocoon/sunshine/connector Tag: cocoon_2_0_3_branch ResourceConnectorImpl.java Log: Synchronizing branch with HEAD: Adding fix for Xalan bug Revision ChangesPath No

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

cziegeler2002/10/10 23:30:41 Modified:src/scratchpad/src/org/apache/cocoon/sunshine/connector Tag: cocoon_2_0_3_branch ResourceConnectorImpl.java src/java/org/apache/cocoon/xml Tag: cocoon_2_0_3_branch XMLUtils.java Log:

RE: Variable Expanders

Stefano Mazzocchi wrote: > 1) from the user's point of view, input modules act as namespaced > sitemap variables (you said that) > > 2) that means that just like the user knows that type="xslt" will > match the transformer associated with 'xslt', the variable > {request:skin} will match t

Re: new JSR on Java Compiler API

I am interested to participate in the discovery stage. If I can bring enough value I will stay longer in the group. I assume this standard covers XSLTC as well. Is the XSLTC team invited ? What I would like to see in future is XSLT and Java programs being compiled and debugged in the same envir

RE: [Announcement] sitemap variables

Stefano wrote: > > > > > > > > > > > where the only problem is the nesting of two components of > the same type > (but I don't really see a need for this and I would think > it's a design > mistake of the component if you need to do it!) Yes it probably

Re: [Announcement] sitemap variables

Hmmm, after restating that I hate actions and I hate nested actions even more because of {../../../1} let me state that I would hate them *even* more if we go the Torsend's {///1} way. Sylvain proposed the {[1]1} path and don't know about you, but that made me puking all over the floor. (Sorr

Re: new JSR on Java Compiler API

On Thursday, October 10, 2002, at 03:58 PM, Stefano Mazzocchi wrote: > People, > > Neal Gafter is about to start the process for a new JSR on Java > Compiler API which would hopefully make it fir Tiger (aka Java 1.5). > He asked me if there are people interested in helping out with the > deta

Re: [vote] Steven Noels and Bertrand Delacretaz as committers

+1 for each. My congrats for attracting them in the team. Ovidiu On Wednesday, October 9, 2002, at 06:02 PM, Diana Shannon wrote: > A recent discussion about a so-called "documentation team" prompted an > offline discussion among some of us about the need for more > "documentation-oriented"

DO NOT REPLY [PATCH QUEUE] Summary October 11 2002

--- This mail is generated automatically using Jakarta Ant. Contents are automatically downloaded from Apache's Bugzilla. --- Please do not reply to t

new JSR on Java Compiler API

People, Neal Gafter is about to start the process for a new JSR on Java Compiler API which would hopefully make it fir Tiger (aka Java 1.5). He asked me if there are people interested in helping out with the details of bootstrapping this from Apache and since we (and Tomcat) are the one who n

Re: Variable Expanders

Stefano Mazzocchi wrote: > Piroumian Konstantin wrote: > >> Ok. I'll give a real Use-Case and you look at it with your critical >> glance. > [forrest use-case goes here] >> from the >> user's point of view, input modules act as namespaced sitemap variables, >> e.g.: >> >> >> >> So, instead of

Variable Expanders

Piroumian Konstantin wrote: > Ok. I'll give a real Use-Case and you look at it with your critical glance. > Maybe we are too input-module-minded after so many discussions and are > FS-infected. Thanks, I really needed that. > Forrest's Use-Case > == > > Prerequisites >

Re: [Announcement] sitemap variables

Sylvain Wallez wrote: > > > The sitemap variables are, as you say, a list and not a tree. Writing > "../" makes sense because - a tree node having only one parent - it > has the same meaning in a list an in a tree : "go to the previous > element". > > To crawl the list from its start, using t

Re: [Announcement] sitemap variables

> The sitemap variables are, as you say, a list and not a tree. Writing > "../" makes sense because - a tree node having only one parent - it has > the same meaning in a list an in a tree : "go to the previous element". > > To crawl the list from its start, using the "/" seems to me a bad choice

RE: defaulting to a matcher when another one is not present

>> Umm, forgot to comment on this: if I invoke another classes methods I'm >> certainly free to deal with any exception as I see fit? It seems to me that >> a sitemap doesn't implement the equivalent of composition either... > > A sitemap is not a class either, it doesn't have methods. > The analo

Re: [Announcement] sitemap variables

[EMAIL PROTECTED] wrote: > > > > >>>this still stands... >>> >>> >>I left it out, because it's the most difficult thing ;-) Childs in pipelines >> >>are the nested components, aren't they? But what's the consequence for this >> >>syntax? The child tree you posted in a former mail uses com

Re: [Announcement] sitemap variables

> > this still stands... > > I left it out, because it's the most difficult thing ;-) Childs in pipelines > > are the nested components, aren't they? But what's the consequence for this > > syntax? The child tree you posted in a former mail uses components as > directories and variables as f

Re: [vote] Steven Noels and Bertrand Delacretaz as committers

Hi All, On Wed, Oct 09, 2002 at 09:02:16PM -0400, Diana Shannon wrote: > > David Crossley and I would like to nominate two individuals who have... +1 > > Steven Noels: indefatigable committer of the Forrest documentation... +1 Welcome guys! :) Cheers

RE: defaulting to a matcher when another one is not present

>> Is this necessary? Probably not. > > In fact, in the above scenario it isn't. How would you suggest handling it with Cocoon today? >> Is there any reason not to allow it? >> Probably not. > > Let me disagree. > > A sitemap is a *contract*. Well that's the basis for the disagreement.

Re: Remove the deprecated Notification stuff in org.apache.cocoon.*in 2.1?

Stefano Mazzocchi wrote: > Nicola Ken Barozzi wrote: > >> The Notification classes in org.apache.cocoon.* have been moved since >> quite some time now in the components/notification, and I would not >> mind if we remove it from there. >> >> Since they have already been deprecated for some time

DO NOT REPLY [Bug 13479] - Cocoon fails to compile sitemap and XSP in JBoss 3.0.3 with embedded Tomcat 4.1.12 and 4.0.5

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_b

Re: [vote] Steven Noels and Bertrand Delacretaz as committers

Nicola Ken Barozzi wrote: > Diana Shannon wrote: > >> David Crossley and I would like to nominate two individuals who have >> repeatedly demonstrated their ongoing commitment to the Cocoon >> community, its documentation, and its code in the form of patches, >> participation, and leadership.

Re: [Announcement] sitemap variables

Carsten Ziegeler wrote: >The more I think about this approach, the more I like it. >But, I see some problems here: >- First one is of course name clashes - I should not define > a param-prefix which is either already used or already > defined by an input module. > My experience with Cocoon is l

RE: [vote] Steven Noels and Bertrand Delacretaz as committers

+1 for both :) J. === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no inten

Re: [Announcement] sitemap variables

Torsten Curdt wrote: > On Thursday 10 October 2002 04:24, Joerg Heinicke wrote: > We already have XPath. Why use it? Because its like all computer related thing teached us for years. Everybody know that ".." means parent. >>> >>>but the question is - what means child? >> > > this still s

DO NOT REPLY [Bug 13479] - Cocoon fails to compile sitemap and XSP in JBoss 3.0.3 with embedded Tomcat 4.1.12 and 4.0.5

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_b

RE: Remove the deprecated Notification stuff in org.apache.cocoon.* in 2.1?

> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] > > The Notification classes in org.apache.cocoon.* have been moved since > quite some time now in the components/notification, and I > would not mind > if we remove it from there. > > Since they have already been deprecated for some time

Re: Remove the deprecated Notification stuff in org.apache.cocoon.*in 2.1?

Nicola Ken Barozzi wrote: > The Notification classes in org.apache.cocoon.* have been moved since > quite some time now in the components/notification, and I would not mind > if we remove it from there. > > Since they have already been deprecated for some time and I honestly > doubt anyone was

RE: [Announcement] sitemap variables

> -Original Message- > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 09, 2002 9:27 PM > To: [EMAIL PROTECTED] > Subject: Re: [Announcement] sitemap variables > > > Amir Rosen wrote: > > > >>-Original Message- > >>From: Torsten Curdt [mailto:[EMA

Re: Remove the deprecated Notification stuff in org.apache.cocoon.* in 2.1?

On Thursday 10 October 2002 12:28, Nicola Ken Barozzi wrote: > The Notification classes in org.apache.cocoon.* have been moved since > quite some time now in the components/notification, and I would not mind > if we remove it from there. > > Since they have already been deprecated for some time an

Remove the deprecated Notification stuff in org.apache.cocoon.* in2.1?

The Notification classes in org.apache.cocoon.* have been moved since quite some time now in the components/notification, and I would not mind if we remove it from there. Since they have already been deprecated for some time and I honestly doubt anyone was using them directly anyway, I propose

RE: Chaining order (Re: [VOTE] Input module chaining)

> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] > Piroumian Konstantin wrote: > >> > So the user would say {default:skin}, and get the 'skin' request > parameter, or if not present, 'defaultSkin'. > > IMO this is backwards. The user should use {request:skin}, not > {de

Re: Chaining order (Re: [VOTE] Input module chaining)

> And why is Torsten is talking about "filters"? At least *this* I can explain :) A request should always be considered harmful - bad - and evil. You should never directly use request parameters directly to e.g. to construct a path or even a sql statement. (it's not totally bad currently beca

RE: Chaining order (Re: [VOTE] Input module chaining)

Stefano Mazzocchi wrote: > Sorry for playing devil's advocate, but that's my self-inflicted role, > you know? :) > And we (at least I do) appreciate this role very much - so keep on playing! Carsten - To unsubscribe, e-mail: [

Re: [vote] Steven Noels and Bertrand Delacretaz as committers

Diana Shannon wrote: > A recent discussion about a so-called "documentation team" prompted an > offline discussion among some of us about the need for more > "documentation-oriented" committers. As more and more users are getting > involved with Cocoon documentation development via the lists, w

Re: [Announcement] sitemap variables

Amir Rosen wrote: > >>-Original Message- >>From: Torsten Curdt [mailto:[EMAIL PROTECTED]] >>Sent: Tuesday, October 08, 2002 7:42 PM >>To: [EMAIL PROTECTED] >>Subject: [Announcement] sitemap variables >> >> >>I've added support for absolute addressing of sitemap variables. >> >>Instead of

Re: Chaining order (Re: [VOTE] Input module chaining)

Piroumian Konstantin wrote: >>From: Jeff Turner [mailto:[EMAIL PROTECTED]] >>On Tue, Oct 08, 2002 at 01:17:28PM +0400, Piroumian >>Konstantin wrote: ... >> So the user would say {default:skin}, and get the 'skin' request parameter, or if not present, 'defaultSkin'. IMO this is

Re: [SUMMARY] input module chaining

Carsten Ziegeler wrote: > Piroumian Konstantin wrote: > >>>I think we (= Cocoon community) should clarify our opinion >>>about this first. This includes: >>>- Do we have a simple Sitemap InputModule Component? >> >>We have simple InputModule Component and it's not a sitemap component at >>all.

Re: [SUMMARY] input module chaining

On Wed, Oct 09, 2002 at 06:55:19PM +0200, Christian Haul wrote: > On 09.Oct.2002 -- 08:54 AM, Carsten Ziegeler wrote: > > Ok, I think the first sentence here is one central point of problem: > > Currently I (and it seems others as well) see input modules only as > > components to be used in the si

RE: [SUMMARY] input module chaining

Piroumian Konstantin wrote: > > > > > I think we (= Cocoon community) should clarify our opinion > > about this first. This includes: > > - Do we have a simple Sitemap InputModule Component? > > We have simple InputModule Component and it's not a sitemap component at > all. > > > - Are the cur

Re: [Announcement] sitemap variables

On Thursday 10 October 2002 08:02, Carsten Ziegeler wrote: > The more I think about this approach, the more I like it. > But, I see some problems here: yepp > - First one is of course name clashes - I should not define > a param-prefix which is either already used or already > defined by an

Re: [Announcement] sitemap variables

On Thursday 10 October 2002 04:24, Joerg Heinicke wrote: > >>We already have XPath. Why use it? Because its like all computer related > >> thing teached us for years. Everybody know that ".." means parent. > > > > but the question is - what means child? this still stands... > Sorry for my destru

DO NOT REPLY [Bug 13479] - Cocoon fails to compile sitemap and XSP in JBoss 3.0.3 with embedded Tomcat 4.1.12 and 4.0.5

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_b

DO NOT REPLY [Bug 13479] New: - Cocoon fails to compile sitemap and XSP in JBoss 3.0.3 with embedded Tomcat 4.1.12 and 4.0.5

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_b

Re: [vote] Steven Noels and Bertrand Delacretaz as committers

A warm +1 for both ! Sylvain Diana Shannon wrote: > A recent discussion about a so-called "documentation team" prompted an > offline discussion among some of us about the need for more > "documentation-oriented" committers. As more and more users are > getting involved with Cocoon documentat

Re: MS XDocs and cocoon

On Thursday 10 October 2002 09:26, Denis wrote: >. . . > I just wanted to know your feeling about the upcoming MS Tool XDocs > http://www.microsoft.com/office/xdocs/default.asp >. . . If I'm able to cut through the marketing-speak correctly, this looks like nothing more than a forms editor that