Hi, Ralph. > It would be helpful to me to know in a little more detail what > you are trying to do. On what basis is it determined what should > be dynamically aggregated?
Well, most of the usual cases cover a situation such as, for example: +----------------------------------------+ | Some header with dynamic content | +----------------------------------------+ | | | Some body with dynamic content | | | | | +----------------------------------------+ | Some footer with dynamic content | +----------------------------------------+ In this case, <map:aggregate> is PERFECT because you KNOW in advance that the page will have a header, a body, and a footer. For the sake of establishing a common vocabulary, let's call the header, the body, and the footer "page components", with the understanding that page components may be artibrarily complex. Now, in my case, there is now way of knowing in advance what the page components are or how they should be handled. All I have is the name of the component and a standard way of handling each one, i.e.: 1. generate the contents 2. do the component layout 3. do the presentation of the contents So, the author is able to simply supply a component, which has a predetermined structure and interface (with layout and presentation transforms, for example). Also, each component is completely independent from each other component. The author is able to mix and match components according to her needs. As a simple example, consider a page that contains a "helloWorld" component. We all know that "normally", we would use simple aggregation, like for example: <map:aggregate element="StaticPage" prefix="exp" ns="http://konova.com/ns/expedition/expedition"; label="aggregatePage" > <map:part src="cocoon:/helloWorld.html"/> </map:aggregate> <snip/> Later in an internal-only pipeline: <map:match pattern="*.html"> <map:generate type="jx" src="components/{1}/component.jx"/> <map:transform src="components/{1}/transforms/html/doLayout.xslt"/> <map:transform src="components/{1}/transforms/html/doPresentation.xslt"/> <map:transform src="context://util/stripNamespaces.xslt"/> <map:serialize type="xml"/> </map:match> The above uses an internal pipeline to process the "helloWorld" part into HTML output. Simple. Clean. No problems. Gotta love <map:aggregate>! But, with what I am trying to do, this is not how Cocoon is "told" about what components to process. Cocoon may be "told" about them either through request parameters or a configuration XML file that could be sent to a pipeline, but not in the sitemap. I don't know the exact mechanism right now, but at the same time, I don't really care because I don't think that it should really matter. The point here is that each "part" or "component" is not known at the time of sitemap authoring, but is somehow passed in as a parameter at runtime. So, in effect, I am looking for a way to do something like this: <map:aggregate element="DynamicPage" prefix="exp" ns="http://konova.com/ns/expedition/expedition"; label="aggregatePage" > <forEach component> <map:part src="cocoon:/component.html"/> </forEach> </map:aggregate> Why? Because as I mentioned in my last post, using CInclude is really messy; difficult to manage, maintain, and debug; slow to process; and just plain frustrating! Seems to me that if there were some way of doing what I mention here, life would be good again. ;-) Hope my explanation is understandable... :-/ Thanks! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
