Here is a newer version where postback occurs somewhat correctly going through the jsf lifecycle again when the webflow included view is to be rendered.
here in my views are the challenges..
1) webflow 2.0 currently manages entire jsf lifecycle out of the box including view...
2) but for a jsf taghandler to work the following things need to happen
a) when an active webflow attempts to render the view instead of just rendering the JSF lifecycle has to begin again checking to see if the included view is already a jsf view and applying request parameters targeted to it and validations targetted to it. In addition the new view should not be a full render. It needs to render as children of the targetted webflow container that fired off the flow in the first place
b) JSF needs to store this view somewhere for post back but this has the following issues.
i) When jsf post back, in the case of tabs it will find the the page has not actually change and will attempt to do postback on the full page with the encoding webflows outside of the context of a webflow thread.. This this needs to be prevented and postback should only occur on the portions of this page where the components are not within a webflow
ii) deriving this view and corresponding store should not interfere with the original jsf page
3) Icefaces sometimes cast to BridgeFacesContext which causes ClassCast errors. (specifically this occurs with the focus API, it may occur other places.
So with these challenges i have "LUCKED" into a situation where a lot of this works but it needs to be better thought through with both the experts at icefaces and spring webflow.
Outstanding issues are:
1) for some reason as of yet identified, populated selectitem list are getting duplicated somehow by the framework.
2) ClientId's do not appear to match what icefaces thinks.. Don't know if it's integration or bug in icefaces. focus api reports that it can't find component that I focused on.