9.14 Action Bar Application Design Considerations
It is hard to understand how flexible and functional an action bar application can be by just reading guides and manuals. The only real way to find this out is to set up a small prototype system and try it out. How to do this is described in Prototype an Action Bar.
The following points are things that you should consider when planning or designing applications that are to use action bars.
- Unless you are committed to CUA 1989, and are prepared to possibly alter the way you design midrange application systems, you will find that you are generating large amounts of RDML code to "fight against" that natural flow and architecture built into the LANSA implementation of action bars (in support of CUA 1989).
- Not all types of applications are suitable for action bar implementations. Refer to the CUA 1989 guidelines following for more details in assisting you to make this decision.
- Action bars require more frequent, but usually more compact, screen panel interactions. They may not be suitable for use over slow communications lines. However, in some instances, the compact nature of action bars and pull downs may actually be more suitable on a slow communications line than traditional menu driven applications. There is only one way to find out the suitability of an action bar implementation on a communications link: implement a small prototype application and try it out.
- Never attempt to design a full scale action bar system at your first attempt. Always attempt a small prototype system first to gain the required design and programming experience and to judge the suitability of the application for an action bar approach.
1. Create a process of type ACT/BAR, and include into it one RDML function called PROTO, like this:
DISPLAY FIELDS(#AB$OPT #PD$OPT) IDENTIFY(*DESC)
PANEL_ID(*NONE)
2. After keying in the RDML command, compile function PROTO to assemble the prototype action bar. This dummy function shows the values of the special AB$OPT and PD$OPT fields from the action bar and pull down option chosen.
3. Define in the action bar control table all required action bar options, and all associated pull down choices so that they all cause function PROTO to be invoked.
- Once this has been done the action bar exists and can be used. When any pull down option is chosen it will invoke PROTO showing you the chosen action bar option code and pull down choice code.
- This allows the complete action bar to be assembled, visualized and checked for completeness before generating any full scale RDML functions.
4. The prototype can then be gradually converted to a complete application by successively generating the required RDML code for each pull down option, and replacing action bar control table references to PROTO with the "real" function.
Including other advanced CUA features such as prompt key processing into an action bar application design is vital if the design is to be simple, yet highly functional.
9.14.1 Applications Least Suitable for Action Bar Implementation
9.14.2 Applications Most Suitable for Action Bar Implementation