Difference between coaches and heritage coaches
The coaches in IBM® Business Process Manager V8.5.5 are different in construction from the heritage coaches in V7.5.1 and earlier versions of IBM BPM.
The primary difference between coaches and the heritage coaches of previous versions is that coaches consist of one or more coach views. Coach views are reusable collections of user interfaces that are frequently bound to a data type. This reusability means that you can share common pieces of user interface between coaches. For example, you can create a coach that has a coach view that contains a set of address fields. That is, the coach view is bound to an Address business object and the individual fields are bound to parameters of that business object. If you create a second coach that needs address fields, you can reuse the coach view. Conversely, with heritage coaches you must re-create the address fields. You can now implement your own custom controls as coach views and then reuse these custom controls in other coach views and coaches.
- Coaches introduce a client-side model to coaches to apply the Web 2.0 appearance and behavior. The coach has data on the client, which is available to all of the coach views. That is, fields in different coach views that are bound to the same data object update without requiring a full-page refresh. The coach framework and the stock control coach views use Dojo 1.8.6.
- Instead of the one-button mechanism of heritage coaches, coach views use named boundary events. Programmers use boundary events for actions such as data updates with the server and flows to other coaches or services. For example, a coach can have multiple buttons. In the human service diagram, you can wire each button to a different event. Any coach view can declare and fire a boundary event. You are not limited to using only buttons to do so although, of the stock controls, only the button stock control can fire a boundary event. Furthermore, the programming for coach views consists entirely of client-side JavaScript. There is no need for server-side JavaScript.
- Coaches support collaboration while heritage coaches do not. More than one person can work on the same coach instance at the same time in their own browsers. For example, with collaboration, users can call on colleagues to help them complete a coach instance. These users see which controls their colleagues are editing and the values that they are setting in those controls. Collaboration is available only if the service flow uses coaches for its user interface. If the service flow contains one or more heritage coaches, collaboration is not available.
- The control ID of a coach is different from the control ID of a heritage coach. The control ID of a heritage coach is the div node ID. This is not the case in coaches because coach views are reusable and you can have multiple views in a coach. In coaches, the control ID is the value of the data-viewid attribute of a <div></div> tag. By using the data-viewid attribute, coach view developers can locate the nested view because data-viewid is unique within its parent or enclosing view.
In IBM BPM, services use coaches for the user interface. A human service flow can use coaches only; heritage coaches are not supported by the web-based human services. A heritage human service flow can mix coaches and heritage coaches so that one type can flow into the other. However, a coach cannot contain heritage coach elements, and heritage coaches cannot contain coach views. That is, a user interface for a heritage human service must be a coach or a heritage coach, but not a mix of the two.
| Coach | Heritage Coach |
|---|---|
 |
 |
- The palette contains coach views that you can drop into the coach. Although some stock controls and other palette items have the same name in heritage coaches, these items are implemented differently.
- The palette uses tags to categorize the coach views that are available. You can use the filter to show or hide the categories of coach views.
- The properties area for coach views has different pages from the properties area for heritage coach controls and sections. However, many of the properties in heritage coach controls have a corresponding property in coach views. For example, the page that is named after the heritage coach control contains properties such as Label, Binding, and Control Id. In coach views, you can find corresponding properties on the General page. Many of the heritage coach presentation properties have a corresponding coach configuration option. Even when heritage coach controls and coach views have properties that have the same name, the implementation of those properties can be different.