You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Raphaël Piéroni <ra...@aql.fr> on 2007/11/21 17:19:34 UTC
[Cocoon 2.2] Dynamically redirecting to another block pipeline
Hello,
I would like to redirect from a block to another block.
But this redirection is a little special because:
- the name of the block is dynamically found
- the name of the pipeline in the called block is always the same
- it is possible that the block to be called is created long after the
calling one
(therefore i can't define the dependency in the servlet-service.xml)
Is this achievable? if yep, how?
Regards,
Raphaël
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [Cocoon 2.2] Dynamically redirecting to another block pipeline
Posted by Raphaël Piéroni <ra...@aql.fr>.
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 base64
> 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 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).
>
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
Regards,
Raphaël
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [Cocoon 2.2] Dynamically redirecting to another block pipeline
Posted by Grzegorz Kossakowski <gk...@apache.org>.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [Cocoon 2.2] Dynamically redirecting to another block pipeline
Posted by Raphaël Piéroni <ra...@aql.fr>.
Grzegorz Kossakowski a écrit :
> Raphaël Piéroni pisze:
>
>> Hello,
>>
>
> Hello Raphaël
>
Hi Grzegorz,
>
>> I would like to redirect from a block to another block.
>> But this redirection is a little special because:
>> - the name of the block is dynamically found
>>
>
> 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.
>
>> - the name of the pipeline in the called block is always the same
>> - it is possible that the block to be called is created long after the
>> calling one
>> (therefore i can't define the dependency in the servlet-service.xml)
>>
>> Is this achievable? if yep, how?
>>
>
> Unfortunately, as for now I fear it's not possible to achieve but it wouldn't be that hard to extend
> current functionality to support dynamic connection to other blocks.
>
> Before I go into details I would like to hear about your use-case. I've been wondering if supporting
> dynamic block connection is a good idea recently. I came to conclusion that in most situations I
> could imagine dynamic block connections are *not* needed.
>
> Therefore I would like to hear more details about your case.
>
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)
Regards,
Raphaël
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [Cocoon 2.2] Dynamically redirecting to another block pipeline
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Raphaël Piéroni pisze:
> Hello,
Hello Raphaël
> I would like to redirect from a block to another block.
> But this redirection is a little special because:
> - the name of the block is dynamically found
Could you explain how the concrete block is chosen? What has an effect on making choice?
> - the name of the pipeline in the called block is always the same
> - it is possible that the block to be called is created long after the
> calling one
> (therefore i can't define the dependency in the servlet-service.xml)
>
> Is this achievable? if yep, how?
Unfortunately, as for now I fear it's not possible to achieve but it wouldn't be that hard to extend
current functionality to support dynamic connection to other blocks.
Before I go into details I would like to hear about your use-case. I've been wondering if supporting
dynamic block connection is a good idea recently. I came to conclusion that in most situations I
could imagine dynamic block connections are *not* needed.
Therefore I would like to hear more details about your case.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org