Skyway Builder 6.2 has undergone some big changes in the web layer. In addition to adding support for Spring Web Flow, the support for Spring MVC has been enhanced. The signature of an operation can now be explicitly defined, and a broader set of objects can be used as command objects and model attributes. Furthermore, variables can now be added to a Controller.
In Skyway Builder 6.1, the approach for implementing the model of a Spring MVC application was to create a single object called a Model that contained all the variables and constants needed by an operation, which is used to implement web methods. Operations were defined under these model objects, and all operations contained underneath a model shared the model variables. Any and all variables that you wanted to accept as input data, return as output data, or use locally with an operation for execution were defined in a Model. This approach was effective and technically accurate, however developers really wanted more fine-grained control in the definition of web methods.
Note: In previous versions of Skyway Builder, the web methods of a controller were called Actions. In Skyway Builder 6.2, Actions have been renamed to Operations. This was done to bring the implementation of controllers into alignment with services, which both have a concept of operations that have input and output parameters. The implementation of service and controller operations is nearly identical. The term Action is now used to refer to the artifact that’s used for implementing operations using a model-based approach (Skyway Steps).
As result of developer feedback, we decided to enhance the flexibility of the web layer. In Skyway Builder 6.2, the signature of an operation can now be specified. It’s still possible to implement applications using the earlier approach; however, the new approach gives the developer fine-grained control over the data that can passed into and exposed from an operation. It also opens access to additional data, including the request object, the response object, the session object, the locale, request parameters, and validation errors. This enhancement also lets you define operation variables that are used for implementing the operation logic. Operation variables can not be manipulated externally, and are only available to JSP pages if explicitly mapped to an output variable.
Another change is that you can now define controller variables. Controller variables are generated as Spring @ModelAttributes in the code, and they are available to all operations defined under the controller. The variable name is used as the name of the model, and it’s used to reference the variables from the operations defined under the controller and from JSP pages.
Along with the definition of operation signatures, operations can now use any data type as a parameter. Developers are no longer limited to using the Skyway Model objects. As a matter of fact, the use of Skyway Model objects is completely optional. You can use anything that is supported by Spring, including domain objects, form backing objects or primitive variables. A model is still useful for aggregating a set of related variables and exposing them as a single @ModelAttribute, and a model also has configurable scope (request and session). If you have data that you want span multiple requests, a session-scoped model can be used instead of defining session scope controllers.
In order to support these changes, the Skyway meta-data model had to change a bit. In the diagram below, you see that Operations and Models are now peers. A Controller can have a Model and Operations as direct descendants.
To stay in the loop on the upcoming 6.2 release, please follow us on Twitter or join the Skyway Community. As one of the many benefits of joining our community, you will automatically receive product announcements and updates.
