Carsten Ziegeler wrote:
Hi,

I'm not sure if this is you're problem, but the input module is used
in your sitemap (in a parameter). This means the input module is
evaluated before the pipeline is executed. Which means if a transformer
puts data into the session then an input module that is in the same
pipeline definition can never get this value as the input module
is running first.


Carsten



-----Original Message-----
From: Simon Hutchinson [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 10, 2004 2:42 PM
To: [EMAIL PROTECTED]
Subject: Problem with the SessionContext InputModule when using portal-fw


Hi all,

It is a little difficult for me to post a decent test case as it would involve a pretty big chunk of the portal-fw stuff so I am hoping that someone might recognise my simplified view of the problem.

Test Pipeline 1. This pipeline reads in a root element.
The first transformation creates a new context in the session which is transformed afterwords by the session transformer.
The readfromsession.xsl transformer then reads this info back from the session.


(writetosession.xsl)
<xsl:template match="/">
<session:createcontext name="test"/>
<session:setxml context="test" path="teststring">12345</session:setxml>
</xsl:template>


(readfromsession.xsl)
<xsl:template match="/">
    <div>
        <p> here is the session info </p>
        <session:getxml context="test" path="teststring"/>
    </div>
</xsl:template>

(sitemap.xmap)
<map:match pattern="testsession">
        <map:generate type="file" src="root.xml"/>
        <map:transform src="writetosession.xsl"/>
        <map:transform type="session"/>
        <map:transform src="readfromsession.xsl"/>
        <map:transform type="session"/>
        <map:serialize type="xml"/>
</map:match>


My coplet submits to this pipeline and displays the expected response


"here is the session info
12345"


My issue however is that I need to pass the information from the session using the SessionContext input module.
Test Pipeline 2 This pipeline reads in a root element.
The first transformation creates a new context in the session which is transformed afterwords by the session transformer.
The pipline then attempts to pass the data from the session using the SessionContext input module as a parameter to an xslt transformer


The snippet below illustrates the principle.


(writetosession.xsl) as above


<xsl:param name="sessionid"></xsl:param>


(readfromsession2.xsl)
<xsl:template match="/">
<div>
<p> here is the session info <xsl:value-of select="$sessionid"></xsl:value-of></p>
</div>
</xsl:template>


(sitemap.xmap)
<map:match pattern="testsession">
<map:generate type="file" src="root.xml"/>
<map:transform src="writetosession.xsl"/>
<map:transform type="session"/>
<map:transform src="readfromsession2.xsl">
<map:parameter name="sessionid" value="{session-context:test/teststring}"/>
</map:transform>
<map:serialize type="xml"/>
</map:match>




When called directly this pipeline returns as expected ie "here is the session info 12345"

Howver when called from a coplet the session data is not returned.

No errors are being logged.

Has anybody experiences similar issues whilst using the SessionContext input module with a coplet ?

I would appreciate any assistance with this.
In the mean time I shall look at the differences in the source between accessing the sesison from the transformer and from the failing input module.


Kind regards

Si


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]





--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Hi Carsten,


Thanks for the reply

That is exactly what my issue is,
I hadn't realised that input modules were evaluated first.
by going directly to the pipiline with my browser I must have accidently
been reading data put into the session at an earlier stage,

This has solved my problem

Si


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to