Raphaël Piéroni pisze: > Grzegorz Kossakowski a écrit : >> Raphaël Piéroni pisze: >> >> >> Hello Raphaël >> > Hi Grzegorz, >> >> >> Could you explain how the concrete block is chosen? What has an effect >> on making choice? >> > Yup, an http request parameter is contains a hint to the name of the block. > That parameter is base64 encoded. So i will need an action to decode it.
I'll need to ask further questions. Who is responsible of making these links containing base64 encoded block names? Your application? How it's going to know what options are available? > My use case is that my client might define new outputing formats. those > formats are defined > using xslt, and are stored in different jars. > I just want these jars (that the client can put in the war's classpath) > to be usable without modifying the > core servlet service of the webapp (which reside in the main block jar) What about using extension in this case? I mean you create a pipeline (let's name it "rawData") that will serve raw (XML) data in your "core" block. Then for each format you could create separate block _extending_ core and containing one pipeline and having pipeline looking like this: <map:match pattern="output.html"> <map:generate src="servlet:/rawData"/> <!-- Data will be obtained from parent block that is "core" one in this case --> <map:transform type="xslt" src="something.xsl"/> <map:serialize type="html"/> </map:match> You could even go without extension and just by connecting to core block in blocks responsible for output formats. Basically the main idea is to invert control so core block becomes a data provider instead of service consumer (where service would be serializing to some output format). -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
