At Microsoft, I have worked on Office Accounting and Dynamics GP Workflow prior to my current project – the GP web client. I mostly worked on the UI features of web client before I started working on the Window Ribbon feature. Window Ribbons, as the name implies, appears to be a purely UI concept. That’s true, however there are many dependencies to make Window Ribbons render on web client such as sanScript code and Dexterity support/enhancements that will be explained in depth in this series of articles.
Note: Click on the images for larger versions.
Are most of you aware that the Dynamics GP desktop client already has a Ribbon rendered on its list pages?
The web client will have a similar Ribbon with the same features rendered on its window. All non-modal windows by default will have a Window Ribbon displayed when they are rendered in Dynamics GP web client.
Default Ribbon Rule
There are hundreds of windows that require a Window Ribbon on the Dynamics GP web client. Instead of creating a Window Ribbon definition for each of those windows separately (which is not only time consuming but also a maintenance challenge), we designed a set of default Window Ribbon rules that will be applied to each window that requires a Window Ribbon on the Dynamics GP web client. Here are some of those rules:
Rule 1: Ribbon Groups
A Window Ribbon must have predefined groups in the following order and Window Ribbon groups will be displayed only if items exist for that group.
Form level menus
Rule 2: Action Group
All Push Buttons and Button Drop Lists (BDL) in control area (except for a few that belong to an exception list) must be part of Actions Window Ribbon Group.
Some Push Buttons (e.g. field “Ok Button”) if exist in footer of the window should go in to Actions Window Ribbon Group.
Rule 3: Form level menus
Form-level menus are used to add menu items that are specific to a single form. They are created using the form definition window.
Each form level menu will have respective Window Ribbon group when rendered on web client window.
Rule 4: Additional menu
There is a built-in command list (cmdListFormTriggers) that gets rendered as a “Additional” menu on Dexterity window when a form is registered with a trigger (e.g. Trigger_RegisterForm()).
The Additional menu, if it exists on a Dexterity window, must be displayed as the Additional Window Ribbon group on web client window.
Rule 5: GoTo Group
If a “GoTo” button drop list exists in the control area, make it a GoTo Window Ribbon group on the web client window.
Rule 6: Built-in Commands
Several built-in commands are already defined in Dexterity, and can be used in your application. These commands provide access to system-level features, such as the print, print setup, help, copy/paste etc.
The Print (cmdPrint) and Print Setup (cmdPrintSetup) commands from File built-in command will be part of File Window Ribbon group on web client window.
The Help Window Ribbon group on web client window will display the Help menu commands (cmdHelpContents, cmdHelpOnHelp etc).
Additionally, the Window Note will be part of the Help Ribbon group if that button exists in the footer of the window.
To be continued next week…. in this post.
For other posts in this series go to: http://blogs.msdn.com/b/developingfordynamicsgp/archive/tags/developer+insights/