Stefano Mazzocchi wrote:
>:-???
>
>sorry, probably I'm stupid and slow, but I still don't get it
>
Don't say that, as we all now you aren't stupid nor slow !
Ok, I give up with this now, but this will certainly resurface at the
time we will make this real...
>>Has this triggered something in
Stefano Mazzocchi wrote:
> Right now, the note proposed by Eve Maler and Norm Walsh (long time
> contributors of the document-centric XML/SGML world) is a sort of 'ant
> build file for xml processing'. Indeed powerful, but limited in scope
> and many believe too document-oriented.
>
> I wouldn't
> From: Michael Hartle [mailto:[EMAIL PROTECTED]]
>
> Berin Loritsch wrote:
>
> >The problem is that the sitemap exposes everything underneath to the
> >end user. It would be much better if the sitemap markup EITHER
> >supported the resource/view paradigm OR purely the pipeline
> paradigm.
Berin Loritsch wrote:
>The problem is that the sitemap exposes everything underneath to the end
>user. It would be much better if the sitemap markup EITHER supported
>the
>resource/view paradigm OR purely the pipeline paradigm. The resource
>would specify the pipeline fragment that starts the p
Good post. My comments interspersed (I just got back from vacation,
so maybe the points were already made):
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
>
> In light of the discussion on blocks, Sylvain pointed out
> that cocoon services should be mapped to pipelines and not to
> res
Stefano Mazzocchi wrote:
> Sylvain Wallez wrote:
>
>>Consider the same sitemap with just
>>an additional "what" attribute to :
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>I
Sylvain Wallez wrote:
> >Unfortunately, this requires a different attribute, something like
> >
> >
> >
> >
>
> Interesting thought. Let's keep it for when we will discuss the
> security-related topics of block.
Ok.
>
>
> >For example, we could have done:
> >
> >
> >
> >instead of
> >
> >
Stefano Mazzocchi wrote:
>Sylvain Wallez wrote:
>
>
>>Isn't the regular URI-matching enough that you need an additional naming
>>scheme ?
>>
>>
>
>No, probably not, but in that case, we need another pipeline state.
>
> - [no attribute] -> similar to java 'public'
> - internal-only="true"
"J.Pietschmann" wrote:
>
> Stefano Mazzocchi wrote:
> > In that case I agree: like I said, if you need to do your stuff without
> > Cocoon around, or without a precise way (xpipe?) to define how a
> > document is processed, document() is the way to go. That's the only
> > argument I acknowledge.
J.Pietschmann wrote:
> Stefano Mazzocchi wrote:
>
>> In that case I agree: like I said, if you need to do your stuff without
>> Cocoon around, or without a precise way (xpipe?) to define how a
>> document is processed, document() is the way to go. That's the only
>> argument I acknowledge.
>
Stefano Mazzocchi wrote:
> In that case I agree: like I said, if you need to do your stuff without
> Cocoon around, or without a precise way (xpipe?) to define how a
> document is processed, document() is the way to go. That's the only
> argument I acknowledge.
The problem appears to be that ther
"J.Pietschmann" wrote:
>
> Stefano Mazzocchi wrote:
> > I personally don't like the document() function of XSLT. I normally
> > suggest to use an xinclude stage to perform aggregation when the
> > structure of the aggregation is not fixed, but that's really up to you.
> >
> I personally don't lik
Stefano Mazzocchi wrote:
> I personally don't like the document() function of XSLT. I normally
> suggest to use an xinclude stage to perform aggregation when the
> structure of the aggregation is not fixed, but that's really up to you.
>
I personally don't like Cocoon aggregation, basically
becau
Sylvain Wallez wrote:
> >I've showed how I perceived named pipelines not as 'functions' to call,
> >but as 'small internal URI spaces' (sort of small internal virtual
> >hosts), I think this concept is *much* more powerful than the
> >'resources' we have now and it's much more block-friendly.
> >
Sylvain Wallez wrote:
> Although it is ok to call named pipelines _inside_ a sitemap (that's
> just a name change for resources), I don't like it for _inter sitemap_
> calls, like can or will be the case for subsitemaps and blocks : up to
> now, the input contract of the sitemap is the environmen
"J.Pietschmann" wrote:
>
> Stefano Mazzocchi wrote:
> > - deprecate 'internal-only' attribute of 'map:pipeline'
> >[because named pipelines become implicitly internal-only]
>
> I use something like the following:
>
>
> "document(concat('cocoon://int/news/',$pubdir))/files/
On 04.Jul.2002 -- 03:20 PM, Christian Haul wrote:
> On 04.Jul.2002 -- 11:50 AM, Sylvain Wallez wrote:
> > The redirector used (ForwardRedirector) handles the special "cocoon:"
> > protocol as internal redirects (aka "forward") which should consider the
> > request as internal.
> >
> > However,
On 04.Jul.2002 -- 11:50 AM, Sylvain Wallez wrote:
> The redirector used (ForwardRedirector) handles the special "cocoon:"
> protocol as internal redirects (aka "forward") which should consider the
> request as internal.
>
> However, I noticed Carsten has added a processInternal() method to
> P
Torsten Curdt wrote:
>
> reading this thread it seems we are approaching the
> function-based sitemap...
> expressed in XML. What a lot of people tried to avoid in the flow
> discussion.
>
> Pipelines seem to become more of a function-like programming construct...
> which is not bad at all. IMO it
reading this thread it seems we are approaching the function-based sitemap...
expressed in XML. What a lot of people tried to avoid in the flow discussion.
Pipelines seem to become more of a function-like programming construct...
which is not bad at all. IMO it would make a lot of sitemap const
Carsten Ziegeler wrote:
>
>
>>-Original Message-
>>From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
>>Sent: Thursday, July 04, 2002 11:50 AM
>>To: [EMAIL PROTECTED]
>>Subject: Re: Internal Pipelines (was: [RT] reconsidering pipeline
>&
Diana Shannon wrote:
> Can someone help fill in the holes below?
>
> On Wednesday, July 3, 2002, at 10:10 AM, Jason Foster wrote:
>
>> We should really get this in a FAQ somewhere!
>>
What's the difference between having two pipelines with one matcher
each, and one pipeline with two ma
> -Original Message-
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 04, 2002 11:50 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Internal Pipelines (was: [RT] reconsidering pipeline
> semantics)
>
>
> Christian Haul wrote:
>
> &
Christian Haul wrote:
>Sylvain,
>
>I'm still trying to fully understand flow and the treeprocessor. I
>have the impression, that sending a page does not access internal-only
>pipelines. I found that sendPage uses a redirector to actually send
>the page in AbstractInterpreter.java. Any idea how t
Sylvain,
I'm still trying to fully understand flow and the treeprocessor. I
have the impression, that sending a page does not access internal-only
pipelines. I found that sendPage uses a redirector to actually send
the page in AbstractInterpreter.java. Any idea how this can be marked
as an inter
On 03.Jul.2002 -- 10:51 PM, Sylvain Wallez wrote:
> sitemap, and is only visible from this sitemap. The treeprocessor
> currently "silently" extends the resource definition by allowing a
> resource to be unterminated (i.e. no serializer). This wasn't done on
> purpose (this is in fact a bug if
Can someone help fill in the holes below?
On Wednesday, July 3, 2002, at 10:10 AM, Jason Foster wrote:
> We should really get this in a FAQ somewhere!
>
>>> What's the difference between having two pipelines with one matcher
>>> each, and one pipeline with two matchers?
>>
>> If there is no oth
Jeremy Quinn wrote:
> I never liked map:resource, always having to be at the end, makes them
> far less useful for pipeline reuse!
>
> It's like going to a plumber's merchant to buy some joints and they
> say 'yes we have elbows and tee joints, but they are all pre-assembled
> into special s
We should really get this in a FAQ somewhere!
>> What's the difference between having two pipelines with one matcher
>> each, and one pipeline with two matchers?
>
> If there is no other difference in pipeline declarations, then none.
>
> Pipelines can differ by:
> - visibility: internal (n
On Tue, Jul 02, 2002 at 02:54:37PM +0200, Stefano Mazzocchi wrote:
>
> So, here is what I propose:
>
> - add the 'pipeline' attribute to 'map:call'
> - add the 'name' attribute to 'map:pipeline'
> - deprecate the 'map:resources' element
> - deprecate 'internal-only' attribute of 'map:pipelin
> From: Justin Fagnani-Bell [mailto:[EMAIL PROTECTED]]
>
> I hope this isn't to dumb a question, but I've been wondering
> it for a
> while:
>
> What's the difference between having two pipelines with one matcher
> each, and one pipeline with two matchers?
If there is no other difference in
>> (3) using a pipeline as a serializer
Wouldn't this be useful for having authenticated and non-authenticated
versions of resources? Something like...
-
To unsubscribe, e-
I hope this isn't to dumb a question, but I've been wondering it for a
while:
What's the difference between having two pipelines with one matcher
each, and one pipeline with two matchers?
Thanks a lot,
Justin
-
To unsubsc
>>
>> On Wednesday, July 3, 2002, at 08:30 AM, Gerhard Froehlich wrote:
>>
>>> What are the typical use cases for:
>>
>
>
>
>
>
>>> (3) using a pipeline as a serializer
>>>
>>
>> Dunno
>>
>
>
Ok, ok I have understood :-).
+1 for this idea
TIA for your explanation
Greets
Gerhard
On Tuesday, July 2, 2002, at 01:54 PM, Stefano Mazzocchi wrote:
> In light of the discussion on blocks, Sylvain pointed out that cocoon
> services should be mapped to pipelines and not to resources directly.
>
I totally agree with that suggestion.
>
> We call 'Cocoon pipeline' the collecti
On Wednesday, July 3, 2002, at 10:16 AM, Jeremy Quinn wrote:
>
> On Wednesday, July 3, 2002, at 08:30 AM, Gerhard Froehlich wrote:
>
>> What are the typical use cases for:
>
>> (3) using a pipeline as a serializer
>>
>
> Dunno
>
OK, I'll try again ;)
On Wednesday, July 3, 2002, at 08:30 AM, Gerhard Froehlich wrote:
> What are the typical use cases for:
Sample from :
In practice, this one is already internal, s
Amir Rosen wrote:
>
> > -Original Message-
> > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
>
> > - deprecate 'internal-only' attribute of 'map:pipeline'
> >[because named pipelines become implicitly internal-only]
>
> How can i reproduce the functionality of the given exampl
"Park, Paul" wrote:
>
> Will the pipelines support parameters?
Yes, absolutely.
> Since, its begining to look like named xslt templates, what about something
> like
>
>
>
>
>
>
>
>
>
>
>
Yes, something like this.
Keep in mind that we alread
Stefano,
>
>
>Composing pipelines
>---
>
>Let me assume the above syntax gets introduced. At this
>point, we have four different ways to call a pipeline:
>
> - as a pipeline - as a generator - as a transformer - as a
>serializer
>
>let me write the code so you understand what I m
Stefano Mazzocchi wrote:
>In light of the discussion on blocks, Sylvain pointed out that cocoon
>services should be mapped to pipelines and not to resources directly.
>
>This consideration triggered a few RT that I would like to share with
>you and trigger further discussion.
>
>NOTE: this is not
Stefano Mazzocchi wrote:
> - deprecate 'internal-only' attribute of 'map:pipeline'
>[because named pipelines become implicitly internal-only]
I use something like the following:
...
and in the sitemap
> -Original Message-
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> - deprecate 'internal-only' attribute of 'map:pipeline'
>[because named pipelines become implicitly internal-only]
How can i reproduce the functionality of the given example without the 'internal-only'
de
: Apache Cocoon
Subject: [RT] reconsidering pipeline semantics
[using a pipeline as a pipeline] (as today)
So, here is what I propose:
- add the 'pipeline' attribute to 'map:call'
- add the 'name' attribute to 'map:pipeline'
On Tuesday 02 July 2002 08:54 am, Stefano Mazzocchi wrote:
> So, here is what I propose:
>
> - add the 'pipeline' attribute to 'map:call'
> - add the 'name' attribute to 'map:pipeline'
> - deprecate the 'map:resources' element
> - deprecate 'internal-only' attribute of 'map:pipeline'
>[bec
In light of the discussion on blocks, Sylvain pointed out that cocoon
services should be mapped to pipelines and not to resources directly.
This consideration triggered a few RT that I would like to share with
you and trigger further discussion.
NOTE: this is nothing related to blocks or flow, b
46 matches
Mail list logo
