Options for Very Large Frameworks
Some Frameworks may contain more than 500 business objects. With frameworks this large the start up times, both for users and developers, can become annoying. Additionally having multiple developers working in with a single XML framework definition file may present management issues.
An alternative to a large framework is to subdivide it into multiple smaller frameworks. Assuming you can make the subdivision (on an application or role-orientated basis probably), you could be dealing with for example three frameworks defined like this:
| Entry Point Form Name | Framework XML Definition File |
|
MJDFRAME1 |
Frame_1.XML |
|
MJDFRAME2 |
Frame_2.XML |
|
MJDFRAME3 |
Frame_3.XML |
The three entry point forms would just be normal VLF entry point forms:
Function Options(*DIRECT)
BEGIN_COM ROLE(*EXTENDS #VF_AC006)
Mthroutine Name(uInitializeFramework) Options(*Redefine)
Set Com(#Com_Owner) IDesignMode(FALSE) Uadminmode(FALSE)
Set Com(#Com_Owner) Usystemxmlfile(‘<<Framework’s XML file definition file>>')
Endroutine
End_com
Once you have three frameworks you can put them in a folder on the user desktop and use it like a high level menu:
This menu system offers a high level alternative to the main VLF navigation tree. It also allows end-users a large choice in the way they arrange and display things.
Also, it is usually easier to swap between multiple application areas open in different windows than by moving around in the VLF navigation tree.
You can also fairly easily allow one framework to start up another. This VLF hidden command handler will generically launch another VL form:
BEGIN_COM ROLE(*EXTENDS #VF_AC020)
MTHROUTINE NAME(uExecute) OPTIONS(*REDEFINE)
Use OV_SYSTEM_SERVICE With_Args(START_LANSA ('FORM=' + #Com_Owner.avAlphaArg1))
Endroutine
End_com
Let's say Framework 1 contains applications called Framework 2, Framework 3 and Other Frameworks. The Other Frameworks application also contains business objects titled Framework 2 and Framework 3. In Framework 1 the navigation pane looks like this:
This shows two styles of accessing Framework 2 or 3 from within Framework 1.
If you click on Framework 2 or Framework 3 at any level in the Framework 1 navigation tree, the other framework is launched as another VL process by the generic command handler above.
If Framework 2 contained 300 business objects (say), you have now made them accessible from within Framework 1 without having to bear the overhead of actually having them defined in Framework 1. All you had to do was to add to Framework 1 a single application or business object to act as a link.
The same command handler would be defined for each application and business object, like this:
The salient points are that the command handler is defined as a default command, it does not show on popup menus, it executes as hidden command, and the alpha argument 1 contains the name of the VL form to be launched by the command handler.
You can now start your frameworks from individual desktop icons or from the navigation tree in Framework 1.
There are some additions to this example that are relatively easy to make. You can use:
- A marker file or a data queue to check whether the other framework is already active and avoid starting up another instance.
- Your own logon IIP and an encrypted temporary stream file to pass logon details between frameworks. That way Framework 1 can capture the last set of logon/connection details. When framework 2 or 3 start up they can bypass asking the user to supply the logon details again.
- Data queues to communicate between different frameworks. If each framework has a ‘framework manager’ that listens to an associated queue, it is relatively easy to communicate between the frameworks.
Using techniques like this you can produce a result that is just as integrated and probably easier to use than a single very large framework.