Session Variable in Included Dynament not Accessible on Original Page

[mbyis...@gmail.com]

On a certain page I call an include dynament which sets a session
variable named "GivenChapter". When I then try to access the variable
on the original page, it comes up null:

Original Page:
____________________
Line 22: <rde-dm:include content="forms/session.xml" stylesheet="forms/
session.xsl" />
.
.
.
Line: 2312: <rde-dm:attribute mode="read"
attribute="session:GivenChapter" />
____________________


Dyanment: (forms/session.xml)
____________________
...
<rde-dm:attribute mode="write" source="session"
attribute="GivenChapter" value="test" />
...
____________________


Please note that although I have written "test" as the value with
which GivenChapter is populated in the dynament, in "real life" it is
populated with the results of a web service call.

I think I know what is happening: The read dynament on the original
page (Line 2312) is being called before the included dynament
(session.xml, called in Line 22) has been able to set the GivenChapter
session variable, probably because the web service takes a long time
to return.

So, then, the question is:
(1) Am I right?
(2) And, more importantly, how do I fix the situation?

Thanks,
Michael Klosner,
Senior Developer

[Tim D]

Michael,

Since you've specified a stylesheet you've likely triggered a special feature. This is known as a PSX Module. It makes a separate request that is cache-able separately from the content including it. This is an optimization feature for a personalized region of content so you can cache the content of the include separate from the larger container. If you are just trying to encapsulate some logic separately it is better not to use the PSX module syntax.

PSX will also stop you from being able to share request variables with called and included contents. If this is a form handling html page its probably best to use request variables without PSX and persist all request variables to session/user at the end. Also be aware there are quirks with other scopes such as users as to when values are flushed to DB.

If its form processing page mixed with design it may be best to offload processing to a separate handler file, post/get to that handler then redirect with the process DynaMent so you don't have to worry about caching the handling just any error/success messages.

Best,

Tim Davis