We have a custom human worklist application that show the list of tasks at the top and a dynamic region at the bottom showing the taskflow for the selected task. This region is a dynamic region.
When switching between two tasks of the same type, the dynamic region will refresh as the input parameters change (and refresh=ifNeeded). However all JSF components in that region seem to retain their state, probably since all the component IDs remain the same. So things like af:showDetailHeader retain their collapsed/expanded state. This is confusing to the user as he expects to browse to a new task with a clean state. The user does get a clean state when switching between two tasks that require a different taskflow as all the component IDs change. It's just when switching between two tasks of the same type that the JSF component state is retained.
Wouldn't it be nice if we have a property on the af:region to control whether the JSF components within that region should reset their state when the region refreshes. The default could be to keep the current behavior (not reset state) so existing applications don't break. But in cases like ours we would set the property to reset state when refreshing the region.
If needed I could create a small sample app. It would contain a region with refresh=ifNeeded. Then have a taskflow in that region with an af:showDetailHeader where the user can change the collapsed/expanded state.Then have a button in the wrapper page that changes an input parameter of the taskflow so it refreshes. You notice that the af:showDetailHeader retains its state.