cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raphaël Piéroni <>
Subject Re: [Cocoon 2.2] Dynamically redirecting to another block pipeline
Date Thu, 22 Nov 2007 16:10:07 GMT
Grzegorz Kossakowski a écrit :
> 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
> encoded block names? Your application? How it's going to know what options are available?
another part of my application is reponsible for this, this part is 
shell scripts.
It know the available option by reading a specific configuration file 
but on another server

>> 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
> 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).

The initial XML is uploaded by my shell scripts. Then it is
transformed in a common format (but the xsl is function of
the incoming format whose nae is in the base64 parameter)

The problem here is that after processing the xslt,
the XML is then in a commmon format and
computed by the core to be inserted in the relational Database.

Thanks for all, but it seems a fellow worker found that we could just 
export the xsl using "resource://{xsl_path}"
So i no longer need this kind of feature



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message