Some Frameworks may contain more than 500 business objects. With Frameworks this large the startup times, both for users and developers, can be judged to be excessive. 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|
The three entry point forms would just be normal VLF entry point forms based on UF_EXEC (for VLF-WIN) or UF_OEXEC (for VLF-ONE).
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.
You can also fairly easily allow one VLF-WIN Framework to start up another.
This VLF-ONE 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))
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:
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.