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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
