It resets with the screen widget cache expiration though. If I set
widget.screen.locationResource.expireTime=1000 there is no problem, but if I
set widget.screen.locationResource.expireTime=10000 then there is a problem.
This leads me to believe the following is what is being read by the cache:
First pass (nothing in cache) parameters.dataresourceId=12345
<screen name="main-content">
<section>
<widgets>
<label>${parameters.dataresourceId}</label>
<content dataresource-id="${parameters.dataresourceId}"/>
</widgets>
</section>
</screen>
Second pass parameters.dataresourceId=54321
<screen name="main-content">
<section>
<widgets>
<label>${parameters.dataresourceId}</label>
<content dataresource-id="12345"/>
</widgets>
</section>
</screen>
So, my thoughts are that it is caching the screen definition after it expands
the <content> tag, which would all still be in the widget component and not the
content component.
----- Original Message ----
From: Adrian Crum <[EMAIL PROTECTED]>
To: [email protected]
Sent: Wednesday, September 10, 2008 12:45:10 PM
Subject: Re: Screen Widget Cache, Dataresource, FlexString Error
It's not an issue with FlexibleStringExpander - since the same instance
is being used for both lines (and the instance cache never expires).
I would recommend looking at the content widget - maybe something weird
is going on there.
-Adrian
Chris Howe wrote:
> from today... 693619
>
>
>
> ----- Original Message ----
> From: Adrian Crum <[EMAIL PROTECTED]>
> To: [email protected]
> Sent: Wednesday, September 10, 2008 11:41:06 AM
> Subject: Re: Screen Widget Cache, Dataresource, FlexString Error
>
> What revision are you using?
>
> -Adrian
>
> Chris Howe wrote:
>> I am getting an undesired result with the following:
>>
>> <screen name="main-content">
>> <section>
>> <widgets>
>> <label>${parameters.dataresourceId}</label>
>> <content dataresource-id="${parameters.dataresourceId}"/>
>> </widgets>
>> </section>
>> </screen>
>>
>> On each request with a different dataresourceId value, the <label> updates,
>> but the <content> does not until the
>> widget.screen.locationResource.expireTime cache setting elapses. This leads
>> me to believe that the screen is getting cached after the
>> FlexibleStringExpander does its magic on the content element. I can't
>> imagine this being the expected result. Can anyone help me zero in on the
>> fix while I dig? Thanks.
>>
>