cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miles Elam <>
Subject Re: map:aggregate / map:part does only work with XML files?
Date Mon, 01 Sep 2003 20:37:20 GMT
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

Be careful.  That's conspicuously close to the definition of an XML 
pipeline in Cocoon.  Also, something like

  <map:generate type="file" src="foo.xml"/>
  <map:generate type="directory" src="foo/"/>
  <map:generate type="custom" src="bar"/>

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.

>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  However, in the archives, you can find Stefano's proposal and resulting 
thread of discussion 

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:
For additional commands, e-mail:

View raw message