You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by ch...@bluewin.ch on 2003/09/01 10:12:50 UTC
map:aggregate / map:part does only work with XML files?
hi everybody,
I'm using cocoon version 2.1.
I would like to use map:aggreagte to aggregate two XML documents from different
sources. I hae written a custom generator and I would like to use it in the
map:part element.
unfortunately this does not work!
in the generator element I use it like this and it works fine:
<map:generate type="atlasextract">
...some map parameters..
</map:generate>
in the aggregate element i would like to use it as follows:
<map:aggregate element="root">
<map:generate type="atlasextract">
...some map parameters..
</map:generate>
<map:generate type="atlasextract">
...some map parameters..
</map:generate>
</map:aggregate>
is there a way to achieve this or does it only work with XML files?!
Thanks in advance,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: map:aggregate / map:part does only work with XML files?
Posted by Upayavira <uv...@upaya.co.uk>.
christianmenz@bluewin.ch wrote:
>hi everybody,
>
>I'm using cocoon version 2.1.
>
>I would like to use map:aggreagte to aggregate two XML documents from different
>sources. I hae written a custom generator and I would like to use it in the
>map:part element.
>
>unfortunately this does not work!
>
>in the generator element I use it like this and it works fine:
>
><map:generate type="atlasextract">
>...some map parameters..
></map:generate>
>
>in the aggregate element i would like to use it as follows:
>
><map:aggregate element="root">
><map:generate type="atlasextract">
>...some map parameters..
></map:generate>
>
><map:generate type="atlasextract">
>...some map parameters..
></map:generate>
>
></map:aggregate>
>
>is there a way to achieve this or does it only work with XML files?!
>
>
do:
<map:match pattern="atlasextract.xml">
<map:generate ..../>
<map:serialize type="xml"/>
</map:match>
then:
<map:aggregate element="root">
<map:part src="cocoon:/atlasextract.xml"/>
...
You might want to put the 'atlasextract.xml' into a <map:pipeline
internal-only="yes"> pipeline.
Regards, Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: map:aggregate / map:part does only work with XML files?
Posted by rufio <ru...@op.pl>.
on Mon, 01 Sep 2003 13:37:20 -0700 Miles Elam <mi...@pcextremist.com>
wrote:
> Also, something like
>
> <map:aggregate>
> <map:generate type="file" src="foo.xml"/>
> <map:generate type="directory" src="foo/"/>
> <map:generate type="custom" src="bar"/>
> </map:aggregate>
>
> looks a bit odd to me. Then again, that may simply be because I'm not
> used to it. It would definitely require some retooling of the
> pipeline code to accommodate.
This looks odd, but think os using two generators of the same type used
on different source or used on the same source but with different
parameters; aggregator's params allow you to make output looking like
directly from generator.
> <whatever/>
>
> It just so happens that the developers have been talking about doing
> away with resources in favor of pipeline fragments. The thread
> appears to be missing(!?!) on marc.theaimsgroup.com. However, in the
> real-time.com archives, you can find Stefano's proposal and resulting
> thread of discussion
> (http://archives.real-time.com/pipermail/cocoon-devel/2003-August/018
> 386.html).
Couldn't open the url nor find the result (big tree thread), but after
reading the first paragraph of the Stefano's proposal I think VPC could
resolve problems I mentioned.
> But the same point applies to aggegated generators too I guess.
Virtual Pipeline Componets + aggregator taking any generator
would made aggregating resources problem nonexisted.
<BTW about="map:resource">
map:resource really looks like map:match with literal pattern (no
special chars) that ends with xml serializer and is putted in internal
pipeline, ie. resource looks like pipeline part and AFAIR docs doesn't
say it's not.
Considering this, map:resource looks like component intended for sitemap
modularisation, and internal pipelines looks like workaround for use
with aggregators.
IMO simplest workaround for this would be special protocol for
map:resources (probably outdated by virtual pipeline components).
</BTW>
I think that's all.
Regards, Rufio
--
nmap -sS -O -p80,81 www.microsoft.com
[..]
Running: Linux 2.5.X
OS details: Linux Kernel 2.4.18 - 2.5.70 (X86)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: map:aggregate / map:part does only work with XML files?
Posted by Miles Elam <mi...@pcextremist.com>.
rufio wrote:
>simply: all other generators (if we can assume that map:part takes role
>of file generator) can't be used here.
>
>
I guess I was biased here because I've rarely wanted the raw output of
bult-in generators (except FileGenerator) without first passing it
though a transformer or two first. I can see your point especially with
a custom generator.
>I didn't say anything about readers - "anything that produses SAX
>events"
>
>
Be careful. That's conspicuously close to the definition of an XML
pipeline in Cocoon. Also, something like
<map:aggregate>
<map:generate type="file" src="foo.xml"/>
<map:generate type="directory" src="foo/"/>
<map:generate type="custom" src="bar"/>
</map:aggregate>
looks a bit odd to me. Then again, that may simply be because I'm not
used to it. It would definitely require some retooling of the pipeline
code to accommodate.
>There are two situations where you really need to call pipeline from
>map:part :
>- as you mentioned - debugging
>- situations where you really *want* to call them
>
>
And keeping your pipelines modular and flexible.
>but
>
>putting anything-that-produces-SAX-events in map:part would be
>simply more intuitive.
>
>
I think you mean <map:aggregate>, but I get your point.
>Hmm, I think map:resource would be good use case.
>What is the sense of having map:resources if I still have to define
>pipelines/matchers for them?
>
>
It just so happens that the developers have been talking about doing
away with resources in favor of pipeline fragments. The thread appears
to be missing(!?!) on marc.theaimsgroup.com. However, in the
real-time.com archives, you can find Stefano's proposal and resulting
thread of discussion
(http://archives.real-time.com/pipermail/cocoon-devel/2003-August/018386.html).
But the same point applies to aggegated generators too I guess.
>And one more: every time I call another pipeline isn't there any
>performance issue (during serializing and deserializing) ?
>
>
Not anything significant. If the URI lookup were a serious constraining
point of performance, the whole thing would be unusable long before you
actually hit the pipelines. Performance analyses and actual profiling
data are always welcome though.
>BTW IMO sitemap is like programming language - I program the cocoon.
>But in other programming langs I can use for() in another for()
>or if() in if() or even call method from another method
>Why I can't use, for example map:aggregate in map:aggregate?
>
>
Here you lost me. Adding in this functionality is what many developers
(one in particular) calls "flexibility syndrome" or FS for short. I'd
suggest searching the archives for that term. The discussions are quite
interesting. What you propose would turn the sitemap in Apache HTTPd's
mod_rewrite. All of the flexibility of sendmail with all of the cryptic
and unmaintainable issues that entails.
The sitemap has something like "if" with regard to pipeline matching
if (URI1 matches) {
execute pipeline 1
} else if (URI2 matches) {
execute pipeline 2
}
and actions (eg. resource exists) can act as if-statements after a
fashion. There are no looping constructs though. Unlikely there ever
will be. The sitemap was never intended to be Turing-complete. This is
not through lack of effort. This is by design. The sitemap was not
intended for programmers; They are not the intended audience. It is
for the site managers and administrators (who may happen to be
programmers but not necessarily so). Things that make the sitemap
simpler are welcome. Adding complexity on the other hand causes klaxons
to sound off in the community.
For logic like for-loops and do-whiles and all of their ilk
(increasingly the if-statements as well), I encourage you to take a look
at Flow. It may help to ease some of your programmer anxiety. It may
even solve some problems you never even knew you had. ;-)
- Miles Elam
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: map:aggregate / map:part does only work with XML files?
Posted by rufio <ru...@op.pl>.
on Mon, 01 Sep 2003 11:12:39 -0700 Miles Elam <mi...@pcextremist.com>
wrote:
> rufio wrote:
>
> >And I thing aggregator should be able to take anything that produces
> >SAX events - generators/resources/whatever, so people didn't have to
> >use pipeline-for-generator workaround.
> >
> >
>
> It can. <map:part src="..."/> can take a remote URI, a local absolute
> URI, a local relative URI, and the output of another pipeline. What
> exactly is the limitation?
simply: all other generators (if we can assume that map:part takes role
of file generator) can't be used here.
> For all intents and purposes from the user
> point of view, <map:part/> is a generator. If readers et al. (read:
> possible non-XML content) were allowed into <map:aggregate/>, Cocoon's
> XML processing contracts would be horribly broken.
I didn't say anything about readers - "anything that produses SAX
events"
> In addition,
> putting what amounts to a full pipeline in the aggregator has issues
> as well which I will explain below.
>
> <stuff-about-debugging>
> <stuff-about-sitemap-mainanance>
>
> So what were the use cases for needing these added semantics to the
> aggregator that outweigh what was just mentioned?
There are two situations where you really need to call pipeline from
map:part :
- as you mentioned - debugging
- situations where you really *want* to call them
but
putting anything-that-produces-SAX-events in map:part would be
simply more intuitive.
Hmm, I think map:resource would be good use case.
What is the sense of having map:resources if I still have to define
pipelines/matchers for them?
And one more: every time I call another pipeline isn't there any
performance issue (during serializing and deserializing) ?
BTW IMO sitemap is like programming language - I program the cocoon.
But in other programming langs I can use for() in another for()
or if() in if() or even call method from another method
Why I can't use, for example map:aggregate in map:aggregate?
Regards, Rufio
--
nmap -sS -O -p80,81 www.microsoft.com
[..]
Running: Linux 2.5.X
OS details: Linux Kernel 2.4.18 - 2.5.70 (X86)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: map:aggregate / map:part does only work with XML files?
Posted by Miles Elam <mi...@pcextremist.com>.
rufio wrote:
>on Mon, 1 Sep 2003 17:43:14 +0200 Bertrand Delacretaz
><bd...@codeconsult.ch> wrote:
>
>
>
>>I think the current way of doing aggregation makes perfect sense if
>>you think of aggregating pipelines, not only generators.
>>AFAIK there are no plans to change this.
>>
>>
>
>And I thing aggregator should be able to take anything that produces
>SAX events - generators/resources/whatever, so people didn't have to use
>pipeline-for-generator workaround.
>
>
It can. <map:part src="..."/> can take a remote URI, a local absolute
URI, a local relative URI, and the output of another pipeline. What
exactly is the limitation? For all intents and purposes from the user
point of view, <map:part/> is a generator. If readers et al. (read:
possible non-XML content) were allowed into <map:aggregate/>, Cocoon's
XML processing contracts would be horribly broken. In addition, putting
what amounts to a full pipeline in the aggregator has issues as well
which I will explain below.
Having these resources in another pipeline has the added advantage of
debugging. If it were specified in the aggregator, it would be much
harder to isolate any problems. As a separate pipeline URI, unit tests
(with finer-grained units) become simpler and more powerful. You can
test the aggregated results and the standalone results independently.
Having worked with Cocoon's sitemap for a while now, I cannot stress
enough how often this comes up.
When finished testing, the standalone URI can be made a private,
internal-use only URI. If you find that your sitemap is becoming
unmaintainable because of these extra matchers etc., have you considered
reviewing your sitemap to make sure your URI space is clean (eg. reduce
or eliminate redundant matchers)? Also, with subsitemaps, it possible
to split up a large and unweildy sitemap into smaller, logical
subsitemaps for readability.
So what were the use cases for needing these added semantics to the
aggregator that outweigh what was just mentioned?
- Miles Elam
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: map:aggregate / map:part does only work with XML files?
Posted by rufio <ru...@op.pl>.
on Mon, 1 Sep 2003 17:43:14 +0200 Bertrand Delacretaz
<bd...@codeconsult.ch> wrote:
> > ...But this looks to me like a workaround ;-), any plans to enhance
> > the aggregate
> > feature?
>
> I think the current way of doing aggregation makes perfect sense if
> you think of aggregating pipelines, not only generators.
> AFAIK there are no plans to change this.
And I thing aggregator should be able to take anything that produces
SAX events - generators/resources/whatever, so people didn't have to use
pipeline-for-generator workaround.
Regards, Rufio
--
nmap -sS -O -p80,81 www.microsoft.com
[..]
Running: Linux 2.5.X
OS details: Linux Kernel 2.4.18 - 2.5.70 (X86)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: map:aggregate / map:part does only work with XML files?
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
> ...But this looks to me like a workaround ;-), any plans to enhance
> the aggregate
> feature?
I think the current way of doing aggregation makes perfect sense if you
think of aggregating pipelines, not only generators.
AFAIK there are no plans to change this.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: map:aggregate / map:part does only work with XML files?
Posted by ch...@bluewin.ch.
Well, I will try that!! Thanks a lot..
But this looks to me like a workaround ;-), any plans to enhance the aggregate
feature?
Rgds,
Chris
>-- Original-Nachricht --
>Reply-To: users@cocoon.apache.org
>Date: Mon, 1 Sep 2003 11:53:47 +0200
>Subject: Re: map:aggregate / map:part does only work with XML files?
>From: Bertrand Delacretaz <bd...@codeconsult.ch>
>To: users@cocoon.apache.org
>
>
>Le Lundi, 1 sep 2003, à 10:12 Europe/Zurich, christianmenz@bluewin.ch a
>écrit :
>>
>> <map:aggregate element="root">
>> <map:generate type="atlasextract">
>> ...some map parameters..
>> </map:generate>
>
>You cannot do that directly, you have to use the cocoon: protocol:
>
>First create a map:match for your Generator
>
><map:match pattern="atlas">
> <map:generate type="atlasextract"/>
> <map:serialize type="xml"/>
></map:match>
>
>Then you can use
>
><map:aggregate element="root">
> <map:part src="cocoon:/atlas"/>
>
>See also http://wiki.cocoondev.org/Wiki.jsp?page=CocoonProtocolExample
>
>--
> Bertrand Delacretaz
> independent consultant, Lausanne, Switzerland
> http://cvs.apache.org/~bdelacretaz/
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: map:aggregate / map:part does only work with XML files?
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Lundi, 1 sep 2003, à 10:12 Europe/Zurich, christianmenz@bluewin.ch a
écrit :
>
> <map:aggregate element="root">
> <map:generate type="atlasextract">
> ...some map parameters..
> </map:generate>
You cannot do that directly, you have to use the cocoon: protocol:
First create a map:match for your Generator
<map:match pattern="atlas">
<map:generate type="atlasextract"/>
<map:serialize type="xml"/>
</map:match>
Then you can use
<map:aggregate element="root">
<map:part src="cocoon:/atlas"/>
See also http://wiki.cocoondev.org/Wiki.jsp?page=CocoonProtocolExample
--
Bertrand Delacretaz
independent consultant, Lausanne, Switzerland
http://cvs.apache.org/~bdelacretaz/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org