FWD » Core Development » User Interface

This is an extension of the idea in #3260-3. The key here is that instead of doing this at conversion time, we should instead allow the regular converted 4GL menuing code to execute (whether it is with static or dynamic menus) and then we can push the tree of definitions to the web client. Each definition is a menu/submenu/menuitem with a label and an ID. The tree structure represents the menu structure. Every time it changes in the Java client, we would push the latest definitions to the embedded web client.

The embedded web client will implement some kind of "breadcrumb" based system of links showing the current menu item (and its parent items) plus with some interactive visualization that allows the dynamic traversal of the menu.

The Java side must implement the notification and push of the menus (a tree structure with labels and some kind of event id) from the Java client to the embedded web client. It must also handle dispatched events forwarded from the web client.

The web client must handle the rendering of the menu and must dispatch events up to Java in response to user input.

Eric has a JS menuing sample done with D3 that may be useful.

Constantin: I don't see a need for anything at conversion. It seems like we can do it all at runtime. Do you have any concerns or thoughts?

Greg Shah wrote:

Constantin: I don't see a need for anything at conversion. It seems like we can do it all at runtime. Do you have any concerns or thoughts?

1. only the menu for the current window should be made visible at a time
2. if a menu is activated (thus current window is changed) and the new window (opened by the menu) has its own menu? How do we get back to the previous window?
3. in embedded mode, the fwd-embedded-driver.p program removes the menu from the window - as it can't be made not-visible AFAIK. Maybe we can let our driver inform the client of the current window's menu?

Maybe we can let our driver inform the client of the current window's menu?

Yes, I think that makes good sense.

1. the mnemonic index
2. the preprocessed label (because of the & char...)

I can do this via two FWD extension attributes (MNEMONIC and PREPROCESSED-LABEL).

The JSON structure will look like this:

{
   "sensitive" : true/false, // if set, all menu-items are disabled (only for root)
   "visible"   : true/false, // if set, menubar is not visible (only for root)
   "menu-items" :
   [ 
      {
         "handle"      : "", // the resource ID
         "type"        : "MENU-ITEM/SUB-MENU",
         "subtype"     : "NORMAL/RULE/SKIP", // only for type=MENU-ITEM
         "label"       : "", // this is the preprocessed 'label' attribute, with mnemonic resolved
         "accelerator" : "",
         "mnemonic"    : 0,1,2,etc, // this is the resolved mnemonic index, in the preprocessed label
         "read-only"   : true/false, // optional, default false 
         "sensitive"   : true/false, // optional, default true
         // "visible"     : true/false, // optional, default true - not used, does nothing for menu-related stuff
         "toggle-box"  : true/false,  // optional, default false
         "checked"     : true/false, // optional, default false,  only for toggle-box
         "menu-items" :
         [
            {
               // recursive, again each element
            }
         ]
      },
      ...
   ]
}

1. menu-drop: for sub-menu
2. value-changed: for toggle-box
3. choose: everything except toggle-box

Sounds good.

Should I work this in 3260b?

It depends on how much time it will take. 3260b is nearly ready to merge to trunk, right?

You make the call.

Greg Shah wrote:

It depends on how much time it will take.

The FWD changes should not take more than a couple of days, the JS changes are the weird part.

BTW, the menus will be part of i.e. p2j.embedded.js (FWD runtime) or do we allow the embedded app to built it as it wishes, and FWD just provides the 'behind the scene' mechanism to get the menubar data and event support?

3260b is nearly ready to merge to trunk, right?

Yes, I'm doing runtime testing now.

You make the call.

I'd like to merge it (both FWD and Hotel GUI) after testing passes.

the menus will be part of i.e. p2j.embedded.js (FWD runtime)

Yes, it should be part of FWD. Later, if applications need some flexibility we can provide some options. But there should be a good default approach that is built in.

Greg, there is this which seems easy to use: https://dojotoolkit.org/reference-guide/1.10/dijit/MenuBar.html

I want to try this (and maybe just keep the work as a standard menu) before digging into something else more fancy.

OK, I think this is a good idea. Getting something working that is decent is important. Later, we may need to do something that implements more of a "breadcrumb" approach but I'm not entirely sure how important that is.

Eric, a question: can Claro CSS co-exist with Bootstrap CSS? Because I have the JS to build a menubar, but there is something wrong with the CSS... the menubar DOM element (a DIV) does not have claro classes in the runtime-applied styles, although they are defined in the DOM (at the DIV element)...

Constantin Asofiei wrote:

Eric, a question: can Claro CSS co-exist with Bootstrap CSS? Because I have the JS to build a menubar, but there is something wrong with the CSS... the menubar DOM element (a DIV) does not have claro classes in the runtime-applied styles, although they are defined in the DOM (at the DIV element)...

Actually, nevermind, the dijit/menubar is pretty stupid/incomplete, there are deficiencies in at least alignment and toggle-box support... if you have an alternative, let me know, otherwise I will try something in SVG, but not before fixing some FWD deficiencies related to event propagation via APPLY.

Constantin Asofiei wrote:

... if you have an alternative, let me know, otherwise I will try something in SVG, [...]

Sorry, I haven't used a library that implements menu widgets per se. I've only worked with Bootstrap's static navbar in a limited way; I haven't done nesting or dropdowns (I'm not sure what's possible in that regard). Googling around a bit, though, it seems like there are a lot of alternatives out there. It may make sense to use an existing implementation before doing something from scratch in SVG.

3331a rev 11174 contains the FWD changes without the complete p2j.menu.js code which is supposed to create the menubar (now is using dijit but this is not displaying properly).

Beside p2j.menu.js, the code is 99% complete I think - just needs to be tested.

3331a passed testing and can be merged to trunk.

Code Review Task Branch 3331a Revision 11176

1. LogicalTerminal.apply() has changes that now allow multiple paths to be taken when previously only one could ever be executed. Since the if/else if/else is now just a series of separate if statements, it seems to me that the same resource might report both res instanceof GenericFrame/GenericWidget as well as !HandleOps.isSystemHandle(res). This seems like it would be possible to execute associated gf/gw.apply() as well as the lt.client.apply(). Is this intended? Is it safe?

2. Please add entries to gaps/expressions.rules for the artificial FWD attributes.

If item 1 (the possible double apply processing) is OK, then you can merge to trunk so long as you've done a quick test to ensure item 2 (the gap analysis change) doesn't break anything.

Greg Shah wrote:

Code Review Task Branch 3331a Revision 11176

1. LogicalTerminal.apply() has changes that now allow multiple paths to be taken when previously only one could ever be executed. Since the if/else if/else is now just a series of separate if statements, it seems to me that the same resource might report both res instanceof GenericFrame/GenericWidget as well as !HandleOps.isSystemHandle(res). This seems like it would be possible to execute associated gf/gw.apply() as well as the lt.client.apply(). Is this intended? Is it safe?

No more than one apply() call to client-side will ever be executed, as there is a return executed after the apply(), in all cases. So it is safe.

2. Please add entries to gaps/expressions.rules for the artificial FWD attributes.

Done in rev 11177.

as there is a return executed after the apply(), in all cases

Good point, I missed that.

Greg Shah wrote:

... then you can merge to trunk so long as you've done a quick test to ensure item 2 (the gap analysis change) doesn't break anything.

3331a was merged to trunk rev 11175 and archived.

Greg, this task can be closed too - the standard/default FWD menu for embedded mode works.