| At line 1 added 24 lines |
| !!!RSF benefits for SWF developers |
|
| [RSF] is a natural fit for [Spring Web Flow (SWF)|SpringWebFlow], since both are web technologies based on the [Spring]'s IoC idiom and libraries. Both frameworks have "universal portability" as a goal, and the intersection of the two leads to a still greater universal portability. Here are some of the benefits that SWF developers could expect from the RSF environment: |
|
| !! [Pure HTML templating|PureXHTMLTemplating] |
| RSF's X(HT)ML [templating engine|PureXHTMLTemplating], [IKAT] is the purest yet created - it adds only a single, namespaced, attribute to its target schema, which leads to straightforward, clean template files which are easy to edit and preview by designers with no coding expertise. This allows a develoepr to keep SWF specifics out of the templating layer which provides for good separation of concerns and more change tolerant code. An RSF template set is also typically ''previewable'', allowing the full application appearance and navigation to be tested from the filesystem, reducing design time and cycle time between designers and developers. |
|
| !! [Spring|SpringFramework]-only world |
| An RSF-SWF application is configured using only standard Spring-formatted XML files. Users need not learn another framework's format or semantics. RSF views are generated using IoC-driven beans known as [Producers|ComponentProducers] which are configured in [request scope|RSAC]. Since they participate fully in injection, there is no need for the "gearing layer" which is traditional in so many other frameworks which is needed to adapt IoC to non-IoC semantics - RSF producers can participate in injection as both sources and targets. |
| |
| !! Universal portability |
| Portability is a core goal of both RSF and SWF. As well as enabling portability to all the existing SWF environments (Servlets, Portlets, and a couple of others such as Sakai) RSF-SWF also enables portability of SWF's flows from its environments where they are not naturally interconvertible. For example, the standard SWF sample "SellItem" is provided in two versions, one on a standard "SpringMVC on JSP" stack and another to JSF. Despite these operating semantically the "same" flow and application definition, the flow files sellitem-simple-flow.xml etc. and sellitem-jsf-flow.xml are not the same, and can not be run in each others environments. However, they can both be run within RSF-SWF, requiring only minor changes to the producers and Spring environment, and none to the templating. An RSF-SWF app can switch transparently from using SWF's form binding scheme to using RSF's, even on a bean-by-bean basis. |
|
| This issue, and data binding schemes in general, is discussed in detail on the page for the port of the [SellItem|SellItemSWFSample] sample. |
|
| !! Courtesies |
| RSF offers two small "courtesies" to SWF developers, which amount to "helpful defaults out of the box". Firstly, on encountering a submission or rendering error, rather than presenting the user with an unfriendly stack trace, the RSF-SWF standard behaviour is to redirect to a default view (under the [Level1Error] system). The exception is logged with a unique key, which could also be rendered to the user if desired. This is particularly helpful in the case of expired flows. |
|
| The second courtesy is that of refreshable flow end states. By default the final page of an SWF flow is not refreshable, and has not resulted from a POST-to-GET redirect ("redirect on pause") transition. RSF resolves this possible brittleness by allocating a short "end state" from its own flow system in which, despite the SWF flow having expired, any "final data" that it requires for rendering will remain visible, even though the flow proper may not be reentered. |
|
| This is discussed in detail on the page for the port of the [SellItem|SellItemSWFSample] sample. |
|
| ---- |
| If you are an existing RSF user interested in the benefits of SWF, check out the [SWF for RSF|SWFforRSF] page. |
