Joerg Heinicke wrote:
On 17.12.2007 0:31 Uhr, Kamal Bhatt wrote:
I have a folder location that is specified in a database. I need to
run a query on the database and generate XML (using an XSP) , as
well, I need to get this folder location and use it to determine the
location of some XSLTs that is later used to transform the generated
XML. Seeing as I am querying the database for XML, I don't want a
situation where I am querying twice.
Something like this:
<map:match pattern="test-xsp-action">
<map:act type="xsp-action" src="my-xsp-action.xsp">
<map:generate type="file" src="test2.xml"/>
<map:transform src="{my-xsp-action-variable}/myxslt.xslt"/>
</map:act>
<map:serialize type="xml"/>
</map:match>
However, I also have the added requirement that I need to support
aggregation, which isn't working in this scenario (that is
my-xsp-action-variable isn't available outside of the associated
match). I want to be able to setup a parameter that is available from
any match/pipeline. In a similar way that flow attributes seem to be.
Now the picture is clearer. The above is one of the pipelines that
should be aggregated. The second map:part should also be configured
dynamically from the database ({testXML} in your other mail).
Unfortunately I don't think this is possible. While flow sets
something like a global context, the action context is local to the
map:act. Even writing it the following way does not help you:
<map:act type="xsp-action" src="my-xsp-action.xsp">
<map:match pattern="test-xsp-action2">
<map:aggregate element="test1">
<map:part src="cocoon:/test-xsp-action"/>
<map:part src="{testXML}"/>
</map:aggregate>
<map:serialize type="xml"/>
</map:match>
<map:match pattern="test-xsp-action">
<map:generate type="file" src="test2.xml"/>
<map:transform src="{my-xsp-action-variable}/myxslt.xslt"/>
<map:serialize type="xml"/>
</map:match>
</map:act>
This works - but the action is executed twice though since there are
two requests that are processed: test-xsp-action2 and
cocoon:/test-xsp-action and both run through this pipeline.
Bummer.
I guess I will have to run the query twice. I guess the saving grace is
that it isn't an expensive query, just a bit annoying that I have to hit
the database twice.
Thanks.
--
Kamal Bhatt
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]