cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/source SourceUtil.java

cziegeler2002/10/09 00:18:57 Modified:src/java/org/apache/cocoon/components/source SourceUtil.java Log: Workaround for serializing xml Revision ChangesPath 1.9 +62 -51 xml-cocoon2/src/java/org/apache/cocoon/components/source/SourceUtil.java Index: SourceUt

RE: [SUMMARY] input module chaining

Thanks Jeff for this summary! Jeff Turner wrote: > > At Carsten's request, I'm attempting to summarise a long (46 email) > thread about input module 'chaining'. See [1] for exactly which mails I > mean. Re-reading it, it seems I'm the only one who was really > confused, but > here's a summary any

RE: Error building the lastest CVS

Thanks Antonio for spotting this. It's fixed now. Carsten > -Original Message- > From: Antonio Gallardo Rivera [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 08, 2002 11:31 PM > To: [EMAIL PROTECTED] > Subject: Error building the lastest CVS > > > Hi, I just want to let you see t

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

cziegeler2002/10/08 23:39:24 Modified:src/java/org/apache/cocoon/components/modules/input GlobalInputModule.java Log: Why does Eclipse always add this import? Hmpf Revision ChangesPath 1.2 +0 -1 xml-cocoon2/src/java/org/apache/cocoon/c

NPE when using profile-caching or profile-noncaching with some transformers

Hello, I'm using the latest cocoon2.1-dev cvs head, SuSE linux 8.0, Tomcat 4.1.10 and jdk 1.3.1. Trying to use the profiling stuff on the latest cvs (profile-caching or profile-noncaching) gives NPE with some transformers, like XMLFormTransformer and Paginator Transformer. While the pipelines

Re: [RT]: InputModules interfaces

On 08.Oct.2002 -- 10:00 PM, Giacomo Pati wrote: > Carsten Ziegeler wrote: > >So, summarizing this, it seems that we agree on changing the InputModule > >interface to > > > >o.a.c.components.modules.InputModule > >{ > > Object getAttribute( String name, Map objectModel ) throws > >ProcessingExcep

Error building the lastest CVS

Hi, I just want to let you see that: Constructing Javadoc information... xml-cocoon2/build/cocoon/src/org/apache/cocoon/components/modules/input/GlobalInputModule.java:60: package sun.tools.tree does not exist import sun.tools.tree.ThisExpression; Antonio Gallardo

Re: [RT]: InputModules interfaces

Carsten Ziegeler wrote: > So, summarizing this, it seems that we agree on changing the InputModule > interface to > > o.a.c.components.modules.InputModule > { >Object getAttribute( String name, Map objectModel ) throws > ProcessingException; > >Iterator getAttributeNames( Map objectModel

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

[EMAIL PROTECTED] wrote: >>>Could you do a >>> >>> >>> >>> >>> >>>or something as last one and cascade the way up? >> >>This should work as well, except that it makes another round-trip to >>the client browser: ugly! > > > you could also use a resource - then it should be an internal redirect

Re: Input module chaining (Re: XML input module)

Piroumian Konstantin wrote: >>From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] >>Quoting Jeff Turner <[EMAIL PROTECTED]>: >> >> >>>Ehm.. more code, less talk :) >> >>Before you guys start coding something that looks like FS >>from 10 Km, please, >>make a formal votation by writing a small des

Re: generic resources

new to test margins with unbreakable-spaces to keep formatting in copy/paste no more html tag in hope that search/replace are not too long - Original Message - From: "Steven Noels" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, October 06, 2002 1:31 PM Subject: Re: gen

Re: the show is over

How much it cost? Antonio Gallardo El Martes, 08 de Octubre de 2002 13:16, Giacomo Pati escribió: > Steven Noels wrote: > > meet the XA35 XML Accelerator > > > > http://www.datapower.com/products/xa35.html > > > > this monster engine will defeat Cocoon ... > > > > ... not ;-) > > I like their "X

Re: the show is over

Steven Noels wrote: > meet the XA35 XML Accelerator > > http://www.datapower.com/products/xa35.html > > this monster engine will defeat Cocoon ... > > ... not ;-) I like their "XML Pipeline Processing™" term best. ;-) Giacomo > (or read the comments from xml-dev where I found this thing: >

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

On Mon, 7 Oct 2002, Carsten Ziegeler wrote: > > Sylvain Wallez wrote: > > > > Carsten Ziegeler wrote: > > > > >Currently I'm -0 but with a tendency to -1. > > > > > >Why? I see these reasons: > > >1) This is an incompatible change - currently if nothing matches in the > > > subsitemap, the erro

Re: [Fwd: Returned Mail / Atgriezts e-pasts!]

Giacomo Pati wrote: > If that address is not subscribed it wouldn't bounce because your reply is > delivered to the list which distributes it to him and then bounce back to > you directly. Checked with Brian: the address was subscribed. I've got 3 or 4 of them in a week time - and one.lv is abo

Re: java.lang.IllegalStateException in 2.1-dev Authentication Framework

Carsten, Thanks for the speedy reply. In doing some more debugging it looks like this exception is raised with old versions of Tomcat. I was running 4.0.4 with the cocoon 2.1-dev head and got this exception (on a clean install). I verified it under Linux as well as FreeBSD. After upgrading to

Re: [Fwd: Returned Mail / Atgriezts e-pasts!]

On Mon, 7 Oct 2002, Steven Noels wrote: > dear apmail, > > this bouncing user apparently isn't detected by ezmlm on > [EMAIL PROTECTED] No, it is bouncing directly to you as the sender of the mail. Ezmlm is only invoked during distribution of your reply to it. > could you check whether he is ef

DO NOT REPLY [Bug 10473] - Adding your own builtin-logicsheets does not work properly

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: cvs commit: xml-cocoon2/src/documentation/xdocs who.xml

Thanks :) Giacomo On 8 Oct 2002 [EMAIL PROTECTED] wrote: > crossley2002/10/08 00:28:14 > > Modified:src/documentation/xdocs Tag: cocoon_2_0_3_branch who.xml > Log: > Sync release branch with head, Sync release branch with head. > > Revision ChangesPath > No

RE: [Announcement] sitemap variables

> -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 writing: > > >

[Announcement] sitemap variables

I've added support for absolute addressing of sitemap variables. Instead of writing: ... ... You can now refer to the first matcher result directly ... ... I also wanted to add

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/treeprocessor/variables PreparedVariableResolver.java

tcurdt 2002/10/08 10:21:59 Modified:src/java/org/apache/cocoon/components/treeprocessor/variables PreparedVariableResolver.java Log: added support for root path sitemap variables {/1}, fixed a disposal bug Revision ChangesPath 1.4 +34 -10

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

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 13410] - Sitemap relaod breaks w/ inputmodule and param

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

[SUMMARY] input module chaining

At Carsten's request, I'm attempting to summarise a long (46 email) thread about input module 'chaining'. See [1] for exactly which mails I mean. Re-reading it, it seems I'm the only one who was really confused, but here's a summary anyway. For the record: input modules are classes which give you

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

On 08.Oct.2002 -- 04:38 PM, Carsten Ziegeler wrote: > Piroumian Konstantin wrote: > > Configuration of input modules is a little different matter. If you have > > good suggestions on how to configure them in the sitemap then nobody will > > have objections, I think. What we couldn't agree on all t

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

On Tue, Oct 08, 2002 at 04:59:45PM +0200, Carsten Ziegeler wrote: [snip sitemap-configured modules] > > Hm, too. :) > > > Anyway, disregarding this issue for a moment (Ugo had similar doubts), > > are there any problems with the basic idea of 'meta' modules that chain > > together other modules?

DO NOT REPLY [Bug 13410] New: - Sitemap relaod breaks w/ inputmodule and param

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: Chaining order (Re: [VOTE] Input module chaining)

Jeff Turner wrote: > > Now, it seems that you all have come to a conclusion for > chaining etc. Just > > post an interface/description for this and we can agree on it > or change it > > until we all are happy. > > I thought these were completely separate issues. Chaining requires no API > chang

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

Jeff Turner wrote: > > > I assume you _want_ to configure the chain in the sitemap? > Yupp! > > And yes: I still believe in SoC, which means a usual Cocoon > user has only > > to edit (and know) the sitemap - he should not care about the > cocoon.xconf. > > How about that config section t

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

On Tue, Oct 08, 2002 at 04:38:45PM +0200, Carsten Ziegeler wrote: > Piroumian Konstantin wrote: > > Configuration of input modules is a little different matter. If you have > > good suggestions on how to configure them in the sitemap then nobody will > > have objections, I think. What we couldn't

RE: [RT]: InputModules interfaces

>> But why throwing a ProcessingException ? Simply throwing Exception would >> avoid exception cascading (I hate these never ending stacktraces) and >> better cope with the variety of implementations. >> > Valid question...now the question is: where do you want to handle the > exception? > If you

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

On Tue, Oct 08, 2002 at 04:22:46PM +0200, Carsten Ziegeler wrote: > > Jeff Turner wrote: > > > > > > > > Just a silly question: are you joking or do you consider this seriously? > > > > Absolutely :) See the other thread. It separates two concerns that are > > currently mixed, and makes module i

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

Piroumian Konstantin wrote: > Configuration of input modules is a little different matter. If you have > good suggestions on how to configure them in the sitemap then nobody will > have objections, I think. What we couldn't agree on all this time was the > modularity and module chaining implementa

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

Antonio Gallardo Rivera wrote: > > > > Yes, ok, if you are all happy with this...I can't stop you from > doing this. > > I personally don't like the concept, because the configuration > is static in > > the cocoon.xconf - I don't see this in the sitemap. > > > > And yes: I still believe in SoC,

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

> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] > Jeff Turner wrote: > > > > > > > > Just a silly question: are you joking or do you consider this > > > seriously? > > > > Absolutely :) See the other thread. It separates two > concerns that are > > currently mixed, and makes module implem

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

El Martes, 08 de Octubre de 2002 08:22, Carsten Ziegeler escribió: > Jeff Turner wrote: > > > Just a silly question: are you joking or do you consider this > > > seriously? > > > > Absolutely :) See the other thread. It separates two concerns that are > > currently mixed, and makes module implemen

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

Jeff Turner wrote: > > > > > Just a silly question: are you joking or do you consider this seriously? > > Absolutely :) See the other thread. It separates two concerns that are > currently mixed, and makes module implementation _much_ simpler. I think > Chris, Konstantin and I are all very happy

RE: [Proposal]: Advanced Value Substitution

Christian Haul wrote: > > First, it's a general approach which works for all components (at least > > those > > looked up using the ComponentManager - it does not work for selectors). > > It is currently used and it works. > > OK. But the "configuration at runtime" argument should hold here, too

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

> From: Christian Haul [mailto:[EMAIL PROTECTED]] > On 08.Oct.2002 -- 10:34 PM, Jeff Turner wrote: > > On Tue, Oct 08, 2002 at 11:54:47AM +0200, Christian Haul wrote: > > > On 08.Oct.2002 -- 01:34 PM, Piroumian Konstantin wrote: > > ... > > Yes!! > > > I think that's really great :) It nicely

Re: [Proposal]: Advanced Value Substitution

On 08.Oct.2002 -- 03:17 PM, Carsten Ziegeler wrote: > Christian Haul wrote: > > > > On 08.Oct.2002 -- 02:17 PM, Carsten Ziegeler wrote: > > > Sylvain Wallez wrote: > > > > > > > > Good, we're in accordance again ;-) > > > > > > > Yup. > > > > > > > However, can you explain the exact purpose of > >

RE: [Proposal]: Advanced Value Substitution

Christian Haul wrote: > > On 08.Oct.2002 -- 02:17 PM, Carsten Ziegeler wrote: > > Sylvain Wallez wrote: > > > > > > Good, we're in accordance again ;-) > > > > > Yup. > > > > > However, can you explain the exact purpose of > > > , and how it is handled ? > > > > > > I see that it is now defined in

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

Carsten Ziegeler wrote: >Sylvain Wallez wrote: > > >>>No, I don't agree here. Yes, components are inherited and yes >>> >>> >>views should imho also be inherited, but this is a >>one-way-street. The main sub sitemap gives control to the sub >>sitemap. You can't use components declared

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

On Tue, Oct 08, 2002 at 11:39:34AM +0200, Carsten Ziegeler wrote: > Jeff Turner wrote: > > > > 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, 'defaultSki

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

On 08.Oct.2002 -- 10:34 PM, Jeff Turner wrote: > On Tue, Oct 08, 2002 at 11:54:47AM +0200, Christian Haul wrote: > > On 08.Oct.2002 -- 01:34 PM, Piroumian Konstantin wrote: > ... > > > > > I imagine this a little different, e.g.: > > > > > > > > > > > > > > class="org.apache.cocoon.components.m

Re: [Proposal]: Advanced Value Substitution

On 08.Oct.2002 -- 02:17 PM, Carsten Ziegeler wrote: > Sylvain Wallez wrote: > > > > Good, we're in accordance again ;-) > > > Yup. > > > However, can you explain the exact purpose of > > , and how it is handled ? > > > > I see that it is now defined in the Processor interface, but can't > > under

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

On Tue, Oct 08, 2002 at 11:54:47AM +0200, Christian Haul wrote: > On 08.Oct.2002 -- 01:34 PM, Piroumian Konstantin wrote: ... > > > > I imagine this a little different, e.g.: > > > > > > > > > > > class="org.apache.cocoon.components.modules.input.SkinModule" > > > > logger="core.module

Re: build docs broken in current 2.1-dev

On Tuesday, October 8, 2002, at 03:51 AM, David Crossley wrote: > "build docs" seems to be broken in 2.1-dev > or it is just mine (2.0.3-dev is fine). > The debug messages do not seem to reveal issues. If you look in the logs, you will see that Cocoon is complaining about not finding the SVGS

RE: [Proposal]: Advanced Value Substitution

Sylvain Wallez wrote: > > Good, we're in accordance again ;-) > Yup. > However, can you explain the exact purpose of > , and how it is handled ? > > I see that it is now defined in the Processor interface, but can't > understand how it is used and what CocoonComponentManager exactly does > with i

Re: [Proposal]: Advanced Value Substitution

[EMAIL PROTECTED] wrote: >Quoting Sylvain Wallez <[EMAIL PROTECTED]>: > > > >>[EMAIL PROTECTED] wrote: >> >> >> I think, the proposed {\1} looks nice. And its very easy to understand. >>>Other comments? >>> >>> >>> >>We don't support absolute paths

Re: [Proposal]: Advanced Value Substitution

Carsten Ziegeler wrote: >Sylvain Wallez wrote: > > >>[EMAIL PROTECTED] wrote: >> >> >> I think, the proposed {\1} looks nice. And its very easy to understand. >>>Other comments? >>> >>> >>> >>We don't support absolute paths for now, although it can easi

Re: [Proposal]: Advanced Value Substitution

Quoting Sylvain Wallez <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] wrote: > > >>I think, the proposed {\1} looks nice. And its very easy to understand. > >> > >> > > > >Other comments? > > > > We don't support absolute paths for now, although it can easily be added > in o.a.c.treeprocessor.v

RE: [Proposal]: Advanced Value Substitution

> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] > [EMAIL PROTECTED] wrote: > > >>I think, the proposed {\1} looks nice. And its very easy to > >>understand. > >> > >> > > > >Other comments? > > > > We don't support absolute paths for now, although it can > easily be added > in o.a.c.tr

RE: [Proposal]: Advanced Value Substitution

Sylvain Wallez wrote: > > [EMAIL PROTECTED] wrote: > > >>I think, the proposed {\1} looks nice. And its very easy to understand. > >> > >> > > > >Other comments? > > > > We don't support absolute paths for now, although it can easily be added > in o.a.c.treeprocessor.variables.PreparedVariableRes

Re: [Proposal]: Advanced Value Substitution

[EMAIL PROTECTED] wrote: >>I think, the proposed {\1} looks nice. And its very easy to understand. >> >> > >Other comments? > We don't support absolute paths for now, although it can easily be added in o.a.c.treeprocessor.variables.PreparedVariableResolver. We also have the (hidden ?) fe

Re: [Proposal]: Advanced Value Substitution

> I think, the proposed {\1} looks nice. And its very easy to understand. Other comments? -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]

RE: [Proposal]: Advanced Value Substitution

Sylvain Wallez wrote: > > Carsten Ziegeler wrote: > > >Good question! Ok, I think you are all right - and I skip my proposal... > >sniff... > > > > > > Don't cry, Carsten, you know we all love you. Maybe next proposal will > be have more acceptance ? > ;-P > Thanks, Sylvain. Hmm, let's se

Re: [Proposal]: Advanced Value Substitution

Carsten Ziegeler wrote: >Good question! Ok, I think you are all right - and I skip my proposal... >sniff... > > Don't cry, Carsten, you know we all love you. Maybe next proposal will be have more acceptance ? ;-P Cheers, Sylvain -- Sylvain Wallez Anyware Technologies Apa

RE: [Proposal]: Advanced Value Substitution

Please don't answer on this one...it's only a joke, really :) Carsten > -Original Message- > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 08, 2002 11:53 AM > To: [EMAIL PROTECTED] > Subject: RE: [Proposal]: Advanced Value Substitution > > > Ok, what do you

RE: [Proposal]: Advanced Value Substitution

> -Original Message- > From: Amir Rosen [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 08, 2002 12:03 PM > To: [EMAIL PROTECTED] > Subject: RE: [Proposal]: Advanced Value Substitution > > > > > > -Original Message- > > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] >

Re: [Proposal]: Advanced Value Substitution

El Martes, 08 de Octubre de 2002 03:38, Carsten Ziegeler escribió: > Sylvain Wallez wrote: > > >So, keeping this short, I propose to change the search algorithm > > >for value substitution: > > >If a key is not found in the inner block, the search is continued > > >up the chain. > > > > Crawling u

Re: [Proposal]: Advanced Value Substitution

Sorry to put my spoon here ;) I think Torsten is right. We cannot make dialects. If the users have now problem with the current syntaxis, this will be even worse if also we will need to ask: "What dialect are you using?" I think, the proposed {\1} looks nice. And its very easy to understand.

RE: [Proposal]: Advanced Value Substitution

> -Original Message- > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 08, 2002 10:36 AM > To: Cocoon-Dev > Subject: [Proposal]: Advanced Value Substitution > > > Hi, > > here is a simple proposal for an easier value substitution algorithm > in the sitemap.

RE: [Proposal]: Advanced Value Substitution

Quoting Carsten Ziegeler <[EMAIL PROTECTED]>: > Ok, what do you guys think about this? > > A configurable variable substitution component! I can configure > in the cocoon.xconf if I want to use the old substitution algorithm > or my suggestion (or a custom implementation). > > Carsten ...that

Re: [VOTE] Input module chaining (Re: XML input module)

On 08.Oct.2002 -- 10:26 AM, Carsten Ziegeler wrote: > Now if I have two different use cases, one with the order you mention > above and one with a different order, let's say 3) - 1) - 2) - 4) how > can I achieve this? > I think if we want to have chaining this must be a little bit more > dynamic -

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

On 08.Oct.2002 -- 01:34 PM, 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 presen

RE: [Proposal]: Advanced Value Substitution

Ok, what do you guys think about this? A configurable variable substitution component! I can configure in the cocoon.xconf if I want to use the old substitution algorithm or my suggestion (or a custom implementation). Carsten > -Original Message- > From: www-data [mailto:[EMAIL PROTECTE

Re: [RT]: InputModules interfaces

On 08.Oct.2002 -- 11:17 AM, [EMAIL PROTECTED] wrote: > Quoting Carsten Ziegeler <[EMAIL PROTECTED]>: > > > Hmm, is it the responsibility of the InputModule to filter? No. > > Or is it rather the calling component which gets information > > from an InputModule that should filter? Yes. > > And

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/treeprocessor/sitemap PipelinesNodeBuilder.java PipelinesNode.java

cziegeler2002/10/08 02:48:01 Modified:src/webapp/samples sitemap.xmap src/java/org/apache/cocoon/components/treeprocessor treeprocessor-builtins.xml src/java/org/apache/cocoon/components/modules modules.xconf

Re: [Proposal]: Advanced Value Substitution

> >here is a simple proposal for an easier value substitution algorithm > >in the sitemap. > > > >Currently, if you nest actions and matchers you have to aware of > >the paths to get your information: > > > > > > > > > > > > > >This can get very complicated. When I first got contact with

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

Jeff Turner wrote: > > 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 backwards. The user should use {request:skin}, >

RE: [Proposal]: Advanced Value Substitution

Sylvain Wallez wrote: > > > >So, keeping this short, I propose to change the search algorithm > >for value substitution: > >If a key is not found in the inner block, the search is continued > >up the chain. > > > > Crawling up the chain can be very expensive ! > Yes, maybe. > >So in the above

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

> 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 backwards. The user sho

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

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 backwards. The user should use {request:skin}, > > not {defaults:skin}. > > > > W

Re: [Proposal]: Advanced Value Substitution

Carsten Ziegeler wrote: >Hi, > >here is a simple proposal for an easier value substitution algorithm >in the sitemap. > >Currently, if you nest actions and matchers you have to aware of >the paths to get your information: > > > > > > >This can get very complicated. When I first got cont

Re: [RT]: InputModules interfaces

On 08.Oct.2002 -- 09:55 AM, Carsten Ziegeler wrote: > > Christian Haul wrote: > > > > On 08.Oct.2002 -- 08:09 AM, Carsten Ziegeler wrote: > > > So, summarizing this, it seems that we agree on changing the InputModule > > > interface to > > > > > > o.a.c.components.modules.InputModule > > > { > >

Re: sitemap design - model and process

Bernhard Huber wrote: > hi, > > I'm thinking about a model for designing a cocoon sitemap. > > You might say just edit the sitemap sitemap.xmap with an editor, > and that's it. > > But I was downloading forrest, and i'm surely impressed by the > nice skin, and the visual design, but i'm a bit t

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

> From: Jeff Turner [mailto:[EMAIL PROTECTED]] > On Tue, Oct 08, 2002 at 10:26:42AM +0200, Carsten Ziegeler > wrote: [snip defaulting example] > > > > > Ok, thanks for your help - sorry, I'm jumping into this a > little bit > > late, but I have to question this concept. As far as I understand

RE: [RT]: InputModules interfaces

Quoting Carsten Ziegeler <[EMAIL PROTECTED]>: > Hmm, is it the responsibility of the InputModule to filter? > Or is it rather the calling component which gets information > from an InputModule that should filter? > And how would you apply this filter, let's say in the sitemap? > Or is it a config

RE: [RT]: InputModules interfaces

Sylvain Wallez wrote: > > >But if you have a method indicating that it throws a ProcessingException > >and it calls a method which simply throws Exception than you have to > >do something like this: > >try { > >inputmodule.method(); > >} catch (ProcessingException pe) { > >// rethrow > >

RE: [RT]: InputModules interfaces

Hmm, is it the responsibility of the InputModule to filter? Or is it rather the calling component which gets information from an InputModule that should filter? And how would you apply this filter, let's say in the sitemap? Or is it a configuration thing? Carsten > -Original Message- > F

Re: [RT]: InputModules interfaces

Carsten Ziegeler wrote: >Sylvain Wallez wrote: > > But why throwing a ProcessingException ? Simply throwing Exception would avoid >exception cascading (I hate these never ending stacktraces) and better cope with the >variety of implementations. >>>Valid question...now the question is

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

On Tue, Oct 08, 2002 at 10:26:42AM +0200, Carsten Ziegeler wrote: [snip defaulting example] > > > Ok, thanks for your help - sorry, I'm jumping into this a little bit > late, but I have to question this concept. > As far as I understand this, the chaining is configured in the cocoon.xconf. > Each

RE: [RT]: InputModules interfaces

Quoting Carsten Ziegeler <[EMAIL PROTECTED]>: > So, summarizing this, it seems that we agree on changing the InputModule > interface to > > o.a.c.components.modules.InputModule > { >Object getAttribute( String name, Map objectModel ) throws > ProcessingException; > >Iterator getAttribut

RE: [RT]: InputModules interfaces

John Morrison wrote: > > > Apart from that just Exception is too specific for me, but I guess > > that's my personal problem here. > > I always thought that Exception was generic not specific... > Ups, yes, thank John - I meant specificI have to write down: Don't think at 8 different things

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

> > Could you do a > > > > > > > > > > > > or something as last one and cascade the way up? > > This should work as well, except that it makes another round-trip to > the client browser: ugly! you could also use a resource - then it should be an internal redirect... btw: do we already hav

RE: [RT]: InputModules interfaces

> Apart from that just Exception is too specific for me, but I guess > that's my personal problem here. I always thought that Exception was generic not specific... > Ok, you say "Exception", I say "ProcessingException" - the next one > in this thread apart from us two can decide which one to use

RE: [RT]: InputModules interfaces

Sylvain Wallez wrote: > >>But why throwing a ProcessingException ? Simply throwing Exception would > >>avoid exception cascading (I hate these never ending stacktraces) and > >>better cope with the variety of implementations. > >> > >> > >> > >Valid question...now the question is: where do you wa

[Proposal]: Advanced Value Substitution

Hi, here is a simple proposal for an easier value substitution algorithm in the sitemap. Currently, if you nest actions and matchers you have to aware of the paths to get your information: This can get very complicated. When I first got contact with value substitution more than t

Re: [RT]: InputModules interfaces

Carsten Ziegeler wrote: >Sylvain Wallez wrote: > > >>Carsten Ziegeler wrote: >> >> >> >>>So, summarizing this, it seems that we agree on changing the InputModule >>>interface to >>> >>>o.a.c.components.modules.InputModule >>>{ >>> Object getAttribute( String name, Map objectModel ) throws

RE: [VOTE] Input module chaining (Re: XML input module)

> -Original Message- > From: Christian Haul [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 08, 2002 9:38 AM > To: [EMAIL PROTECTED] > Subject: Re: [VOTE] Input module chaining (Re: XML input module) > > > On 08.Oct.2002 -- 08:13 AM, Carsten Ziegeler wrote: > > Christian Haul wrote:

Re: Generating a 404 Not Found

Sylvain Wallez wrote: > What about using a dummy action that just throws a > ResourceNotFoundException ? Note also that you don't need to re-match > "admin/**" since it was already matched above. That's a possibility. Before I start coding it (and making it generic enough to be incorporated i

Re: Generating a 404 Not Found

Ugo Cei wrote: > Sylvain Wallez wrote: > >> Do you think it's good for non authenticated users to even know that >> a particular URI in a protected part of the URI space exists or not ? >> I would say no (or tell us your use case), and then your sitemap is >> just fine... > > > No, I think it'

RE: [RT]: InputModules interfaces

Sylvain Wallez wrote: > > Carsten Ziegeler wrote: > > >So, summarizing this, it seems that we agree on changing the InputModule > >interface to > > > >o.a.c.components.modules.InputModule > >{ > > Object getAttribute( String name, Map objectModel ) throws > >ProcessingException; > > > > Itera

build docs broken in current 2.1-dev

"build docs" seems to be broken in 2.1-dev or it is just mine (2.0.3-dev is fine). The debug messages do not seem to reveal issues. -- ... docs: Setup... done. Initializing... ready, let's go :-) * [0] -> [broken link] index.html <- disposing... done. BUILD SUCCESSFUL Total time: 18 secon

RE: [RT]: InputModules interfaces

Christian Haul wrote: > > On 08.Oct.2002 -- 08:09 AM, Carsten Ziegeler wrote: > > So, summarizing this, it seems that we agree on changing the InputModule > > interface to > > > > o.a.c.components.modules.InputModule > > { > >Object getAttribute( String name, Map objectModel ) throws > > Proc

Re: Generating a 404 Not Found

Sylvain Wallez wrote: > Do you think it's good for non authenticated users to even know that a > particular URI in a protected part of the URI space exists or not ? I > would say no (or tell us your use case), and then your sitemap is just > fine... No, I think it's good for *authenticated* u

Re: [RT]: InputModules interfaces

Carsten Ziegeler wrote: >So, summarizing this, it seems that we agree on changing the InputModule >interface to > >o.a.c.components.modules.InputModule >{ > Object getAttribute( String name, Map objectModel ) throws >ProcessingException; > > Iterator getAttributeNames( Map objectModel ) throw

Re: [VOTE] Input module chaining (Re: XML input module)

On 08.Oct.2002 -- 08:13 AM, Carsten Ziegeler wrote: > Christian Haul wrote: > > > > On 04.Oct.2002 -- 11:07 AM, Christian Haul wrote: > > > On 02.Oct.2002 -- 06:38 PM, Stefano Mazzocchi wrote: > > > > > a) if JXPath should be > > > a1) a meta module or > > +0 > > > a2) property of specific modu

RE: Publication on cocoon

Carsten Ziegeler wrote: > David Crossley wrote: > > Carsten Ziegeler wrote: > > > Ok, agreed. I only wanted to give a hint that most > > > articles are already linked in the docs. > > > > > > BTW: What does our documentation team say to this? > > > > (My comments are not directed at any particul

  1   2   >