Could be a bug there; I'll have to figure out how to handle it
properly; likely, it will involve pre-emptively loading values from
the session when the page is "attached" to the request, rather than
waiting until the field value is actually accessed.
On Mon, Apr 23, 2012 at 9:14 AM, Luke Wilson <l...@viscri.co.uk> wrote:
> Hi,
>
> The following documentation in ComponentResources is misleading in Tapestry
> 5.3.2.
>
> /**
> * Discards all persistent field changes for the page containing the
> component. Changes are eliminated from
> * persistent storage (such as the {@link
> org.apache.tapestry5.services.Session}) which will take effect in the
> * <em>next</em> request (the attached page instance is not affected).
> */
> void discardPersistentFieldChanges();
>
> Previously (5.2.6), it behaved as documented, but now (I think) changes to
> the PersistWorker mean that ComponentResources is called when the field is
> accessed, not just when it is set:
>
> public Object get(Object instance, InstanceContext context)
> {
> if (!fieldValue.exists())
> {
> Object persistedValue = resources.hasFieldChange(name) ?
> resources.getFieldChange(name) : defaultValue;
>
> fieldValue.set(persistedValue);
> }
>
> return fieldValue.get();
> }
>
> This means that calling discardPersistentFieldChanges() before accessing the
> persisted fields results in them not being there - "the attached page
> instance is not affected".
>
> Luke
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
