Currently, Spring Web Flow returns logical "view selections" which calling systems use to issue appropriate responses. The advantage of this is it keeps SWF decoupled from the complexity of view rendering. The problem with this is it leads to a good deal of adapter-specific if/else statements (e.g. in MVC, Struts, and JSF) to issue the right response, and it makes it difficult to attach custom flow execution behavior, such as issuing resource cleanup callbacks, to the view rendering lifecycle in a consistent manner.
A good example of a current problem is with Hibernate flow-managed persistence, the session cannot be disconnected before view rendering. Since SWF does not control view rendering, a custom HandlerInterceptor is needed to issue the disconnect callback. This complicates things as a. the handler doesn't have a direct reference to the session and b. its MVC specific -- similiar handlers must exist for the other view technologies Spring Web Flow supports.
As SWF continues to add more features and support more view technologies, this problem is going to get worse. We should investigate putting the view rendering lifectycle under the control of Spring Web Flow. This means SWF view-states would build renderable view selections, capable of actually issuing a suitable response for the given client in the given environment.
Keith Donald opened SWF-367 and commented
Currently, Spring Web Flow returns logical "view selections" which calling systems use to issue appropriate responses. The advantage of this is it keeps SWF decoupled from the complexity of view rendering. The problem with this is it leads to a good deal of adapter-specific if/else statements (e.g. in MVC, Struts, and JSF) to issue the right response, and it makes it difficult to attach custom flow execution behavior, such as issuing resource cleanup callbacks, to the view rendering lifecycle in a consistent manner.
A good example of a current problem is with Hibernate flow-managed persistence, the session cannot be disconnected before view rendering. Since SWF does not control view rendering, a custom HandlerInterceptor is needed to issue the disconnect callback. This complicates things as a. the handler doesn't have a direct reference to the session and b. its MVC specific -- similiar handlers must exist for the other view technologies Spring Web Flow supports.
As SWF continues to add more features and support more view technologies, this problem is going to get worse. We should investigate putting the view rendering lifectycle under the control of Spring Web Flow. This means SWF view-states would build renderable view selections, capable of actually issuing a suitable response for the given client in the given environment.
Affects: 1.0.4
Attachments:
Issue Links:
("is depended on by")
2 votes, 3 watchers
The text was updated successfully, but these errors were encountered: