On 3/17/08, Mark Lundquist <[EMAIL PROTECTED]> wrote:
> On Mar 17, 2008, at 5:17 PM, Mark Lundquist wrote:
> > You might find this interesting:
> > http://thread.gmane.org/gmane.text.xml.cocoon.devel/68380/focus=68408
> whoops, I meant just this:
> http://thread.gmane.org/gmane.tex
Hi Rainer,
On Feb 21, 2008, at 5:49 AM, Rainer Pruy wrote:
Hi,
probably a question with a simple answer.
However, I just failed up to now in getting at it.
wildcard *matcher* is one of the most used components with cocoon,
I'd reckon.
But what to do, when one needs to handle X/c/** an
On Mar 17, 2008, at 5:17 PM, Mark Lundquist wrote:
You might find this interesting:
http://thread.gmane.org/gmane.text.xml.cocoon.devel/68380/focus=68408
whoops, I meant just this:
http://thread.gmane.org/gmane.text.xml.cocoon.devel/68380
:-)
-
Tobia Conforto pisze:
> Rainer Pruy wrote:
>> wildcard *matcher* is one of the most used components with cocoon, I'd
>> reckon. But what to do, when one needs to handle X/c/** and X/**
>> (excluding X/c/**) different? At least if the contained components are
>> not "final" (serialize, read)
>
> Co
Rainer Pruy wrote:
wildcard *matcher* is one of the most used components with cocoon,
I'd reckon. But what to do, when one needs to handle X/c/** and X/**
(excluding X/c/**) different? At least if the contained components
are not "final" (serialize, read)
Cocoon has no URI selector, wildca
Joerg Heinicke schrieb:
>
> Both possible pipeline "paths" would be correct. Only problem is to find
> the mutually exclusive patterns as you run into the second match
> otherwise and have 2 generators. And I think here is where Rainer had
> his problems, there is no "not" to just inverse the fi
On 05.03.2008 20:54, Grzegorz Kossakowski wrote:
- the condition "does not contain C" is not stated easily in terms of wildcard
(just consider: what is the "not" of pattern "**/special treatment_area/**"
and keep in mind, that I do not have control over the undelying namespace
as I then
Rainer Pruy pisze:
> Thanks,
> yes, I am aware of nesting.
>
> To get closer to my question, just assume (may not have been stated clearly
> by me with initial post):
>
> - the condition "does not contain C" is not stated easily in terms of wildcard
> (just consider: what is the "not" of patte
Avoiding duplication of code in XMAPs is handled by "resources":
...
Note that resources can contain any portion of a pipeline and do not
require any specific components. A resource could be just a
Gene
Thanks,
yes, I am aware of nesting.
To get closer to my question, just assume (may not have been stated clearly by
me with initial post):
- the condition "does not contain C" is not stated easily in terms of wildcard
(just consider: what is the "not" of pattern "**/special treatment_area/**"
Are you aware that pipelines can be nested?
http://solprovider.com/lenya/nesting
Each piece of code must start with an Generator/Aggregator and end
with a Serializer (or call a Reader or Redirector.) Think of
as a return statement.
Is this the informa
What about placing a matcher for "X/c/**" above/before "X/**"? Or is my thought
too simple?
Jasha
-Original Message-
From: Rainer Pruy [mailto:[EMAIL PROTECTED]
Sent: Thu 21-2-2008 14:49
To: users@cocoon.apache.org
Subject: Is there an "url wildcard&qu
Rainer
Ok; it was just a suggestion. I won't debate "easy" as that is a
completely
subjective term that no one will agree on :) but I am curious though as
to
what you think would be a "cleaner" solution that a regexp; which are
designed to be powerful and flexible? Perhaps if you have a bette
Derek,
thanks for your answer.
Yes, I'm pretty aware of the possibility of writing my own selector.
A solution based on existing "regexp-header" seemed not really to be easier or
cleaner than what I'm using up to now.
I just am curious whether I did "miss the obvious".
Rainer
Derek Hohls schri
Rainer
I am sure you will get a better answer than this :)
but, off the top of my head, could you not implement
a selector, inside your general case matcher, which could
make use of regular expressions to handle any degree
of complexity - see:
http://cocoon.apache.org/2.1/userdocs/regular-express
Hi,
probably a question with a simple answer.
However, I just failed up to now in getting at it.
wildcard *matcher* is one of the most used components with cocoon, I'd reckon.
But what to do, when one needs to handle X/c/** and X/** (excluding X/c/**)
different?
(At least if the contained co
16 matches
Mail list logo
