The simplest possible PhaseListener I can imagine is one
that just does:
processScope.put("a", "b");
... that is, chucks some nonsense data on, and makes sure that
the system always generates a new token for every request. That'd
be enough to bypass the issue you're encountering.
-- Adam
On 2/28/06, James Moores <[EMAIL PROTECTED]> wrote:
> Adam,
>
> Thanks for getting around answering so many of our questions. I gave up
> on the use of processScope in the end (and switched back to session
> scopes), but I've kept access to all my properties abstracted so I can
> easily switch back to processScopes if/when I can get one of the
> suggested solutions to work. I started on the phaseListener idea but
> quickly realized it would be a bit of a nightmare because each
> initialization is page specific (and phaseListeners aren't), so I might
> now give one of the other ideas a go.
>
> Thanks again to you (and all those others who gave advice on this
> topic),
>
> Cheers,
>
> Jim
> --
> Jim Moores, SmartSpread Ltd, UK.
>
> -----Original Message-----
> From: Adam Winer [mailto:[EMAIL PROTECTED]
> Sent: 26 February 2006 21:21
> To: [email protected]
> Subject: A bunch of belated answers about ADF
>
> <snip>
> - "I use the ADF Faces 'Process scope' facility a great deal...."
>
> This was a problem with values disappearing from the process scope.
> The code was relying on a dummy "get" method being triggered during
> Render Response to do initialization. It does hit a limitation of our
> processScope - it's not thrilled with being mutated during Render
> Response.. Laurie Harper's suggestion of using Shale is a good one;
> with JSF 1.2, a beforePhaseListener on the f:view would work well too.
> You could hack around the processScope limitation by forcibly putting
> something, anything, in the processScope before Render Response, so
> we'll at least generate an ID correctly.
>
> <snip>
> Regards,
> Adam Winer
>
