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]

Reply via email to