6.0.3

From Skyway Wiki

Jump to: navigation, search

The following is a list of significant behavioral changes in Skyway Visual Perspectives Builder made in version 6.0.3

For a complete list of all issues that were addressed in this release, see this JIRA report (note: you will need to log in to JIRA to view the report)


JIRA Issue(s) Products Affected Functional Area Description
MOD-1379

MOD-1400

MOD-1381

CE and EE Project structure and Skyway Navigator Changes to the Skyway runtime execution layer and how code is generated have dictated some changes to how artifacts can be structured under a Skyway project.
  • Folders can no longer be created under Web Controllers and Web Conversations (although existing projects with such Folders will continue to be supported and function correctly). A side-effect of this is that all Web Conversation names under the same Controller must be unique; if an existing project has same-named Conversations in different Folders, a model validation error will now indicate that problem and it must be corrected in order for the project to build and deploy successfully.
  • Data Types and Data Stores can now be created as direct children of the project; previously they could only be located under a Skyway Service or Web Controller.
MOD-1436 CE and EE Web Layer (Controller) The user interface for editing Action Mappings has been re-designed to make it easier to use and improve readability.
. CE and EE Web Layer You cannot directly access JSP pages and have access to Skyway tags and conversation variables. You must access the JSP through an action mapping.


Since there will be times when you want to configure an action mapping just so you can access conversation variables from a JSP, you no longer have to choose an action when you configure an action mapping.

. CE and EE Web Layer A page only has access to the conversations in the controller through which it was accessed. For example, if you access a JSP page through an action mapping on Controller1, then that JSP page can only access variables in conversations under Controller1. JSP pages are therefore implicitly bound to a controller.


Since you cannot access variables across multiple controllers, all variable paths are relative to the controller and not the project; that is, they should no longer start with a controller reference. There are several scenarios where the paths must be relative to the conversation and these scenarios are pointed out below. A reference that used to look like someController.someConversation.someVariable now looks like someConversation.someVariable.

. CE and EE Web Layer When you are posting a form, you can only set variables in a single conversation. So all path attributes of our form tags must be relative to that conversation (e.g. someVariable instead of someConversation.someVariable).
. CE and EE Web Layer There is a checkbox on the action mapping UI that allows you to control request binding. If checked, you can post (via POST or GET) data to that action mapping and the public variables will be set on the specified conversation. If not checked, no variables will be set. If you have requested binding, you must select either an action or a conversation (so we know which conversation to bind to). An action mapping w/ no action that requests binding is ideally suited for the Set Variables command.
. CE and EE Web Layer Since you can only post variables to a single conversation now, you must pick an action mapping when configuring the Set Variables command. And the paths referenced by this command must be relative to the conversation (e.g. someVariable instead of someConversation.someVariable).
. CE and EE Web Layer In an action mapping, if you redirect (client side) to a JSP in the WEB-INF folder, we will automatically emit a bit of magic to make this work.
. CE and EE Web Layer When configuring an action mapping, you can specify an optional Spring validator class (& method) to invoke. This is an advanced option, as it requires you to write the validator class. We’ll invoke this validator class when your action mapping is invoked. While these validators are traditionally used to perform more rigorous validation on data that is posted from a form, you aren’t limited to the *incoming* data; you could validate anything.
. CE and EE Web Layer Since we are using stock request binding from Spring, you can follow typical Spring guidelines/recipes for HTML forms; this includes using the form:errors tag and message bundles.
. EE Data Layer Datasource names generated into Spring have changed. Existing projects deployed to a container that forced you to manually define the Datasource in that container need their JNDI names changed to reflect the new structure.


Retrieved from "http://www.skywayperspectives.org/wiki/index.php/6.0.3"
Personal tools